Jump to content

Quick review of LeMaker's Guitar


tkaiser

Recommended Posts

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:
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

So Thomas, here is the confirmation! It is time do open your USB3-OTG cable carefully and rearrange the cables to their schematic :huh:

- the USB3.0 cable I used is customized -

Although I really wonder where he customized the cable - zoomed in on both pictures and I cannot see that the cable has been changed in any way ???

Hmm, this cable in the picture may be doesn't work and was just used to take the picture.

 

Concerning soldering, in opposite to that movie, cables should be cut at different places each, so a short-circuit is less likely and the cable does not get this thick at one place ;)

Hmm, I don't know if cables in USB are twisted, than this would have to be done on the plug directly.

 

PS: in the thread he added another HDD benchmark

Link to comment
Share on other sites

Sorry, but the Guitar is dead. Way too expensive, high performance only possible when combined with an annoying fan and weird design decisions. Since every standard Micro-USB3-OTG cable does NOT work together with the Guitar they need to bundle such a cable with their baseboard otherwise the advertised feature "USB 3" isn't available.

 

It's moronic to inform customers that they have to customize their cables to use the only interesting feature for a board in this price range: USB3. Without useable USB3 both storage and network performance are way too slow.

 

Even if you're not interested in storage/network performance the Guitar is a bad choice: You have to configure the board to either run slow or you get in trouble due to thermal issues. Due to the brain-dead board layout you can not use GPIO-Add-Ons (Raspberry Pi HATs) and a fan at the same time. So it will be either slow or with limited functionality.

 

Add the software problems (no mainline kernel support, just a horribly outdated kernel 3.10.37 lacking essential features) and you have to come to the conclusion that the Guitar isn't worth the price (the reseller's prices here in Germany are rather high: Baseboard and Coreboard add up to over 90,-€ including shipping and ordering directly from lenovator.com with shipping costs of $33 doesn't make a difference).

 

For less than that I get an ODROID-XU4 (8 CPU cores and not just 4, 2 GByte RAM instead of 1, 2 useable USB3 ports instead of 0, GBit Ethernet instead of Fast Ethernet, experimental mainline kernel support instead of an outdated 3.10.37 kernel being 2450 fixes behind 3.10.92) and for the same price I get two comparable ODROID-C1+ which shares some limitations (kernel 3.10 and no USB3) but is way more attractive due to high performance without thermal issues and GBit Ethernet.

Link to comment
Share on other sites

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

 

Hi tkaiser

 

Would any specific kernel/dtb changes be needed to make a I2S DAC board to function on the Lemaker Guitar ?

Link to comment
Share on other sites

Would any specific kernel/dtb changes be needed to make a I2S DAC board to function on the Lemaker Guitar ?

 

No idea. According to their Wiki I2S is available at the 40 pin GPIO header. But according to their wiki the Guitar is able to output 4096*2048@30HZ through HDMI and drive LCD displays also with 4096*2048 pixel (both wrong. The S500's maximum resolution is 1920x1080 on both HDMI and LCD). You can't trust the informations there as usual. It's just copy&paste from somewhere else and noone of the responsible people gives a sh*t about correct specifications/informations.

Link to comment
Share on other sites

Regarding I2S: I would prefer a solution that works without an annoying fan (byebye S500) and is definitely known to work: http://odroid.com/dokuwiki/doku.php?id=en:c1_hifi_shield(the C1+ is also faster and gets way better support from its manufacturer!)

 

Given the fact that LeMaker shipped their first OS image with a totally wrong display config (native 1024x600 pixel, upscaled to 1920x1080 pixel, again upscaled to 2560x1600 pixel on my display) and that they didn't manage to provide a fix for this over weeks (a forum user just did copy&paste from another .dts file in a trial&error style and solved the problem eventually) I wouldn't expect that you can get any support in case you're running in device-tree related problems from LeMaker (and I don't know how to reach Actions Semi directly -- LeMaker likes to play the intermediary role).

Link to comment
Share on other sites

One final note regarding software support for the Guitar (or any other device using the S500 SoC, currently Lemon/Roseapple Pi). I tried to explain why the S500's kernel version stalls at 3.10.37 (several thousand fixes behind the current 3.10.93 LTS kernel), what's wrong with the so called 'SDK' Actions Semi recently released and why the situation won't change that fast unless at Actions Semi they would really want to become an 'open source community member':

 

http://forum.linux-xapple.org/t/share-ubuntu-14-04-lts-image/130/13?u=tkaiser

http://forum.linux-xapple.org/t/relationship-between-xapple-rose/129/4?u=tkaiser

 

In the meantime I also adjusted RPi-Monitor templates for S500/ATC2603. Works with the Guitar as well but consumption read-out is still WiP: http://wiki.linux-xapple.org/w/index.php/RPi-Monitor#Work_in_progress

Link to comment
Share on other sites

Thank you tkaiser, glad to see you are still digging for this critical info about new arm boards. I had high hopes for the Guitar and its modular design.

 

LeMaker sent me the Guitar test board for review and feedback. I listed many of my concerns which echo your own. None of them seem to have been implemented on updated revisions to the boards.

 

I did my best to explain to them the common use cases for these boards which should be possible with any new boards they release, unless they are targeting a different market. More importantly any new LeMaker devices must be at least as capable as the Banana Pi since that was their own flagship device.

 

My current concerns which need to be fixed before I can recommend this device to users:

  • Cannot power a 2.5" hard drive with a 5V 2A adapter. Nobody wants to have to search for obscure power adapters just to be able to power the board and a hard drive
  • USB 3 micro b makes no sense, I don't know anybody who flashes daily or would like to sacrifice throughput, why wouldn't flashing over USB 2 be sufficient?
  • Gigabit ethernet - because USB 3 makes no sense to me without a fat enough pipe to push it through
  • HDMI-CEC (less important) - supposed to be supported eventually
Link to comment
Share on other sites

Actually flashing any S500 device is USB 2.0 only. They use the Mirco-USB connectors containing the USB 2.0 part solely. This is clear since in the S500's manual it's written that only the USB 2.0 controller is OTG capable. In the meantime they clarified this also in their wiki and the so called 'user manual'. I tried to get informations so many times from them and they either don't answer or don't care about correctness.

 

Last example: Tido asking why /dev/usb will be removed every time the last USB peripheral gets disconnected. And they give him a totally unrelated answer: http://forum.lemaker.org/forum.php?mod=redirect&goto=findpost&ptid=22797&pid=90545

 

Same again here: One person asking for the temperature operation range doesn't get the right answer ("Sorry, this is a tablet SoC and there isn't something like this defined in its datasheet. You can not use it") but random nonsense instead. In the specs the thermal range is specified as "TBD" and both SoC as well as PMIC get way to hot to use this SoC in any commercial application.

 

I asked them 8 questions about an upcoming baseboard revision. And got 0 responses so far.

 

LeMaker's only asset was the community around Banana Pi. But this doesn't exist any longer. People trying to get support for Banana Pi are lost in the meantime.

 

And I doubt you get the idea how "product design" works with cheap SBCs? Almost everything the SBC is able to do depends on the SoC's capabilities. And when you choose a SoC that has neither PCIe nor SATA nor GBit Ethernet and you design the board in a way that the only USB3 port isn't useable... then you have a board that sux.

 

With the original Banana Pi everything was different. Its SoC, the A20, was used in other SBCs already and features both SATA as well as GBit Ethernet, the linux-sunxi community existed already, all LeMaker had to do was collecting already available informations and software and try to build a community around the board. That worked somewhat. Then they were greedy and applied for the Banana Pi trademarks and in the end they had to give up with Banana Pi/Pro (AFAIK they still sell both and at least here in Germany you got many SinoVoip products only through LeMaker resellers and just recently also through SinoVoip's agent)

 

But this will change in the future. And now with Actions Semi they are in a completely different position. The S500 is clearly faster than A20 but lacks many features. Due to the brain-dead Micro-USB connector they prevented anyone from using USB3.0. Regarding know-how and software support for the board everything is completely different. Every question Actions Semi isn't able to answer them won't get answered. And regarding the state of the so called 'SDK' it's a real mess. Software gets fragmented right now, insanely dumb development style, therefore I doubt we will see a newer kernel version anytime soon or at all. No newer kernel means no fixes and no drivers useable that exists only for more recent kernel versions (no driver --> no hardware useable that needs this driver). The Guitar tries to be a modular SoM/SBC concept but given the software state it's an Android only toy with very limited use.

Link to comment
Share on other sites

LOL. They still ship with the moronic display config with an imaginary LCD device being the 'master display' and using 1024x600 resolution upscaled to 1920x1080 on HDMI: http://forum.lemaker.org/forum.php?mod=redirect&goto=findpost&ptid=22515&pid=90542

 

Forum users showed them how this crap can be fixed but they refuse to implement the fix. They simply don't give a sh*t about user's needs ("Hey, who needs working USB3?"). Or they're simply not able to fix the issues with the 'SDK' they got from Actions Semi. 

Link to comment
Share on other sites

I don't see any reason to buy a Guitar.

For applications with limitations in size I use the C1

for others I use the XU3/4 which has a superb performance.

 

I think the Guitar is "just another" board without special highlights.

 

I am much nmore interesed to gat a Bass with its 64bit processor,

but there are not even rumours about availability.

 

 

Link to comment
Share on other sites

I don't see any reason to buy a Guitar.

 

Me too unless they provide a few more baseboards that would make use of the SoM concept. But they're not able to answer even most basic questions, therefore... forget about the Guitar...

 

BTW: LeMaker's competitors (Steed Technology, Allo and Roseapple Pi) at least accepted the S500's thermal challenges: you need large heatsinks for both SoC (and PMIC) otherwise throttling/power-off will occur under load. And both Allo Sparky and Roseapple Pi provide an USB 3.0 type A receptacle so USB 3.0 is useable there (which is still not the case with LeMaker's guitar)

 

Aceberry_S500_Board.jpg

 

Sparky_Allo_Heatsink.jpg

 

 

Bildschirmfoto-2015-12-18-um-11.39.jpg

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines