Search the Community

Devices exist that are able to run OpenWRT/DD-WRT and aren't that expensive, eg this one: https://wiki.openwrt.org/toh/tp-link/tl-wdr4300 In case you've an old 3.5" PATA disk enclosure lying aroung you could use the PSU from this device (dual voltage) and provide power to the router and Banana Pi simultaneously. A 12V PSU and step-down converters will also do the job.

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.

FYI I've found a problem with the nand-sata-install script after building a 4.6 version for my pcduino, nand-part does not exist in /usr/sbin. Did a full, default compile. Seems the command its in the PATH but if i try to run nand-part i get "/usr/sbin/nand-part now found" lf I go manually in there and do a "ls " its there, but even if im in the folder and do ./nand-part same error appears. The error that I'm getting from nand-sata-install is not enough space on nand2, because nand-part is not able to run and aprtition the disk its trying to copy all root to 16MB(old partitioning from stock linksprite image). To make it work for myself i manually compiled nand-part and partitioned the nand properly. Hope it helps, Thanks!

Hello Igor, thanks for your fast reply. I realized it manually with fdisk and reloading the partition table with "hdparm -z /dev/mmcblkp0" to shrink the 16GB SDCard to 1.2GB. Compared to the very small FAT-Bootpartion of a Raspbian (60MB) it's still big but enough for a 2GB SDCard. Does a similiar small FAT-Boot-partition exist before your second boot of armbian? If so - maybe it could be exported or copied just before. Thanks for armbian - love it - donated it !!! with best regards iot

Yes you're right. If the file doesn't exist it use the settings in the init script, so the ondemand. How much power I waste if I set a fixed frequency to the maximum available? My load is often very low.

Hello, First of all thanks for your very good job on armbian !!! I cannot adapt screen resolution on olimex A20 micro + 10 inch LCD (connected on board). normal resolution is 1024x600. I tried some varions in boot.cmd, as : setenv bootargs "console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 hdmi.audio=EDID:0 disp.screen0_output_mode=1024x600@60 panic=10 consoleblank=0 enforcing=0 loglevel=1" many variation as -1024x600 -1024x600 @25 @50 @60 MR-16, or other thinks found on net... The screen never correctly configured. Boot text is bad, graphical work, but not at right resolution visible area is cutted/bad placed...) Did you have advice ? Thanks ! I also tried to use pygame, and i have problem to make glx working. glxinfo answer : "could not find RGB GLX visual or FBconfig" Xorg.log give : [ 20.350] X.Org X Server 1.15.1 Release Date: 2014-04-13 [ 20.351] X Protocol Version 11, Revision 0 [ 20.351] Build Operating System: Linux 3.2.0-67-highbank armv7l Ubuntu [ 20.351] Current Operating System: Linux micro 3.4.109-sun7i #4 SMP PREEMPT Sun Oct 11 14:32:15 CEST 2015 armv7l [ 20.351] Kernel command line: console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 hdmi.audio=EDID:0 disp.screen0_output_mode=1024x600@60 panic=10 consoleblank=0 enforcing=0 loglevel=1 [ 20.351] Build Date: 12 February 2015 02:55:07PM [ 20.351] xorg-server 2:1.15.1-0ubuntu2.7 (For technical support please see http://www.ubuntu.com/support) [ 20.351] Current version of pixman: 0.30.2 [ 20.351] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 20.352] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 20.352] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Oct 25 15:10:15 2015 [ 20.363] (==) Using config file: "/etc/X11/xorg.conf" [ 20.364] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 20.379] (==) No Layout section. Using the first Screen section. [ 20.379] (==) No screen section available. Using defaults. [ 20.379] (**) |-->Screen "Default Screen Section" (0) [ 20.379] (**) | |-->Monitor "<default monitor>" [ 20.381] (==) No device specified for screen "Default Screen Section". Using the first device section listed. [ 20.381] (**) | |-->Device "Allwinner A10/A13 FBDEV" [ 20.381] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 20.381] (==) Automatically adding devices [ 20.381] (==) Automatically enabling devices [ 20.381] (==) Automatically adding GPU devices [ 20.392] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 20.393] Entry deleted from font path. [ 20.393] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist. [ 20.393] Entry deleted from font path. [ 20.393] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist. [ 20.393] Entry deleted from font path. [ 20.393] (WW) The directory "/usr/share/fonts/X11/Type1" does not exist. [ 20.393] Entry deleted from font path. [ 20.393] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist. [ 20.393] Entry deleted from font path. [ 20.393] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist. [ 20.393] Entry deleted from font path. [ 20.393] (==) FontPath set to: /usr/share/fonts/X11/misc, built-ins [ 20.393] (==) ModulePath set to "/usr/lib/arm-linux-gnueabihf/xorg/extra-modules,/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules" [ 20.393] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 20.394] (II) Loader magic: 0xb6f30f10 [ 20.394] (II) Module ABI versions: [ 20.394] X.Org ANSI C Emulation: 0.4 [ 20.394] X.Org Video Driver: 15.0 [ 20.394] X.Org XInput driver : 20.0 [ 20.394] X.Org Server Extension : 8.0 [ 20.394] Initializing built-in extension Generic Event Extension [ 20.395] Initializing built-in extension SHAPE [ 20.395] Initializing built-in extension MIT-SHM [ 20.395] Initializing built-in extension XInputExtension [ 20.395] Initializing built-in extension XTEST [ 20.395] Initializing built-in extension BIG-REQUESTS [ 20.395] Initializing built-in extension SYNC [ 20.395] Initializing built-in extension XKEYBOARD [ 20.395] Initializing built-in extension XC-MISC [ 20.395] Initializing built-in extension SECURITY [ 20.395] Initializing built-in extension XINERAMA [ 20.395] Initializing built-in extension XFIXES [ 20.395] Initializing built-in extension RENDER [ 20.395] Initializing built-in extension RANDR [ 20.395] Initializing built-in extension COMPOSITE [ 20.395] Initializing built-in extension DAMAGE [ 20.395] Initializing built-in extension MIT-SCREEN-SAVER [ 20.395] Initializing built-in extension DOUBLE-BUFFER [ 20.396] Initializing built-in extension RECORD [ 20.396] Initializing built-in extension DPMS [ 20.396] Initializing built-in extension Present [ 20.396] Initializing built-in extension DRI3 [ 20.396] Initializing built-in extension X-Resource [ 20.396] Initializing built-in extension XVideo [ 20.396] Initializing built-in extension XVideo-MotionCompensation [ 20.396] Initializing built-in extension SELinux [ 20.396] Initializing built-in extension XFree86-VidModeExtension [ 20.396] Initializing built-in extension XFree86-DGA [ 20.396] Initializing built-in extension XFree86-DRI [ 20.396] Initializing built-in extension DRI2 [ 20.396] (II) LoadModule: "glx" [ 20.407] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 20.492] (II) Module glx: vendor="X.Org Foundation" [ 20.492] compiled for 1.15.1, module version = 1.0.0 [ 20.492] ABI class: X.Org Server Extension, version 8.0 [ 20.492] (==) AIGLX enabled [ 20.493] Loading extension GLX [ 20.493] (II) LoadModule: "fbturbo" [ 20.494] (II) Loading /usr/lib/xorg/modules/drivers/fbturbo_drv.so [ 20.501] (II) Module fbturbo: vendor="X.Org Foundation" [ 20.502] compiled for 1.15.1, module version = 0.5.1 [ 20.502] Module class: X.Org Video Driver [ 20.502] ABI class: X.Org Video Driver, version 15.0 [ 20.502] (II) FBTURBO: driver for framebuffer: fbturbo [ 20.502] (++) using VT number 7 [ 20.509] (WW) Falling back to old probe method for fbturbo [ 20.509] (II) Loading sub module "fbdevhw" [ 20.509] (II) LoadModule: "fbdevhw" [ 20.516] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [ 20.519] (II) Module fbdevhw: vendor="X.Org Foundation" [ 20.519] compiled for 1.15.1, module version = 0.0.2 [ 20.519] ABI class: X.Org Video Driver, version 15.0 [ 20.519] (II) FBTURBO(0): using /dev/fb0 [ 20.519] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 20.520] (II) FBTURBO(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 20.520] (==) FBTURBO(0): Depth 24, (==) framebuffer bpp 32 [ 20.520] (==) FBTURBO(0): RGB weight 888 [ 20.520] (==) FBTURBO(0): Default visual is TrueColor [ 20.520] (==) FBTURBO(0): Using gamma correction (1.0, 1.0, 1.0) [ 20.520] (II) FBTURBO(0): hardware: (video memory: 3000kB) [ 20.520] (**) FBTURBO(0): Option "fbdev" "/dev/fb0" [ 20.521] (**) FBTURBO(0): Option "SwapbuffersWait" "true" [ 20.521] (II) FBTURBO(0): processor: ARM Cortex-A7 [ 20.521] (II) FBTURBO(0): checking modes against framebuffer device... [ 20.521] (II) FBTURBO(0): checking modes against monitor... [ 20.522] (--) FBTURBO(0): Virtual size is 800x480 (pitch 800) [ 20.522] (**) FBTURBO(0): Built-in mode "current": 33.0 MHz, 31.3 kHz, 59.6 Hz [ 20.522] (II) FBTURBO(0): Modeline "current"x0.0 33.00 800 1009 1039 1055 480 502 503 525 -hsync -vsync -csync (31.3 kHz [ 20.522] (==) FBTURBO(0): DPI set to (96, 96) [ 20.522] (II) Loading sub module "fb" [ 20.522] (II) LoadModule: "fb" [ 20.523] (II) Loading /usr/lib/xorg/modules/libfb.so [ 20.532] (II) Module fb: vendor="X.Org Foundation" [ 20.532] compiled for 1.15.1, module version = 1.0.0 [ 20.532] ABI class: X.Org ANSI C Emulation, version 0.4 [ 20.532] (==) Depth 24 pixmap format is 32 bpp [ 20.540] (II) FBTURBO(0): using backing store heuristics [ 20.573] (II) FBTURBO(0): enabled G2D acceleration [ 20.573] (==) FBTURBO(0): Backing store enabled [ 20.580] (==) FBTURBO(0): DPMS enabled [ 20.580] (II) FBTURBO(0): using sunxi disp layers for X video extension [ 20.580] (II) FBTURBO(0): using hardware cursor [ 20.580] (II) FBTURBO(0): no 3D acceleration because the driver has been compiled without libUMP [ 20.581] (II) FBTURBO(0): if this is wrong and needs to be fixed, please check ./configure log [ 20.581] (==) RandR enabled [ 20.624] (II) SELinux: Disabled on system [ 20.630] (II) AIGLX: Screen 0 is not DRI2 capable [ 20.630] (EE) AIGLX: reverting to software rendering [ 20.631] (EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/swrast_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/swrast_dri.so: cannot open shared object file: No such file or directory) [ 20.631] (EE) GLX: could not load software renderer [ 20.631] (II) GLX: no usable GL providers found for screen 0 [ 20.712] (II) XKB: reuse xkmfile /var/lib/xkb/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm [ 20.731] (II) config/udev: Adding input device axp20-supplyer (/dev/input/event0) [ 20.731] (**) axp20-supplyer: Applying InputClass "evdev keyboard catchall" [ 20.731] (II) LoadModule: "evdev" [ 20.732] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so [ 20.740] (II) Module evdev: vendor="X.Org Foundation" [ 20.741] compiled for 1.15.0, module version = 2.8.2 [ 20.741] Module class: X.Org XInput Driver [ 20.741] ABI class: X.Org XInput driver, version 20.0 [ 20.741] (II) Using input driver 'evdev' for 'axp20-supplyer' [ 20.741] (**) axp20-supplyer: always reports core events [ 20.741] (**) evdev: axp20-supplyer: Device: "/dev/input/event0" [ 20.741] (--) evdev: axp20-supplyer: Vendor 0x1 Product 0x1 [ 20.741] (--) evdev: axp20-supplyer: Found keys [ 20.741] (II) evdev: axp20-supplyer: Configuring as keyboard [ 20.741] (**) Option "config_info" "udev:/sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20-supplyer.28/input/input0/event0" [ 20.742] (II) XINPUT: Adding extended input device "axp20-supplyer" (type: KEYBOARD, id 6) [ 20.742] (**) Option "xkb_rules" "evdev" [ 20.742] (**) Option "xkb_model" "pc105" [ 20.742] (**) Option "xkb_layout" "us" [ 20.746] (II) config/udev: Adding input device Lite-On Technology Corp. USB Mouse (/dev/input/event1) [ 20.746] (**) Lite-On Technology Corp. USB Mouse: Applying InputClass "evdev pointer catchall" [ 20.746] (II) Using input driver 'evdev' for 'Lite-On Technology Corp. USB Mouse' [ 20.746] (**) Lite-On Technology Corp. USB Mouse: always reports core events [ 20.746] (**) evdev: Lite-On Technology Corp. USB Mouse: Device: "/dev/input/event1" [ 20.747] (--) evdev: Lite-On Technology Corp. USB Mouse: Vendor 0x4ca Product 0x30 [ 20.747] (--) evdev: Lite-On Technology Corp. USB Mouse: Found 3 mouse buttons [ 20.747] (--) evdev: Lite-On Technology Corp. USB Mouse: Found scroll wheel(s) [ 20.747] (--) evdev: Lite-On Technology Corp. USB Mouse: Found relative axes [ 20.747] (--) evdev: Lite-On Technology Corp. USB Mouse: Found x and y relative axes [ 20.747] (II) evdev: Lite-On Technology Corp. USB Mouse: Configuring as mouse [ 20.747] (II) evdev: Lite-On Technology Corp. USB Mouse: Adding scrollwheel support [ 20.747] (**) evdev: Lite-On Technology Corp. USB Mouse: YAxisMapping: buttons 4 and 5 [ 20.747] (**) evdev: Lite-On Technology Corp. USB Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 [ 20.747] (**) Option "config_info" "udev:/sys/devices/platform/sw-ohci.1/usb3/3-1/3-1:1.0/input/input1/event1" [ 20.747] (II) XINPUT: Adding extended input device "Lite-On Technology Corp. USB Mouse" (type: MOUSE, id 7) [ 20.748] (II) evdev: Lite-On Technology Corp. USB Mouse: initialized for relative axes. [ 20.748] (**) Lite-On Technology Corp. USB Mouse: (accel) keeping acceleration scheme 1 [ 20.749] (**) Lite-On Technology Corp. USB Mouse: (accel) acceleration profile 0 [ 20.749] (**) Lite-On Technology Corp. USB Mouse: (accel) acceleration factor: 2.000 [ 20.749] (**) Lite-On Technology Corp. USB Mouse: (accel) acceleration threshold: 4 [ 20.750] (II) config/udev: Adding input device Lite-On Technology Corp. USB Mouse (/dev/input/mouse0) [ 20.751] (II) No input driver specified, ignoring this device. [ 20.751] (II) This device may have been added with another device file. [ 20.752] (II) config/udev: Adding input device USB Keyboard (/dev/input/event2) [ 20.753] (**) USB Keyboard: Applying InputClass "evdev keyboard catchall" [ 20.753] (II) Using input driver 'evdev' for ' USB Keyboard' [ 20.753] (**) USB Keyboard: always reports core events [ 20.753] (**) evdev: USB Keyboard: Device: "/dev/input/event2" [ 20.753] (--) evdev: USB Keyboard: Vendor 0x1241 Product 0x1503 [ 20.753] (--) evdev: USB Keyboard: Found keys [ 20.753] (II) evdev: USB Keyboard: Configuring as keyboard [ 20.753] (**) Option "config_info" "udev:/sys/devices/platform/sw-ohci.2/usb5/5-1/5-1:1.0/input/input2/event2" [ 20.753] (II) XINPUT: Adding extended input device " USB Keyboard" (type: KEYBOARD, id 8) [ 20.753] (**) Option "xkb_rules" "evdev" [ 20.753] (**) Option "xkb_model" "pc105" [ 20.754] (**) Option "xkb_layout" "us" [ 20.757] (II) config/udev: Adding input device USB Keyboard (/dev/input/event3) [ 20.757] (**) USB Keyboard: Applying InputClass "evdev keyboard catchall" [ 20.757] (II) Using input driver 'evdev' for ' USB Keyboard' [ 20.757] (**) USB Keyboard: always reports core events [ 20.757] (**) evdev: USB Keyboard: Device: "/dev/input/event3" [ 20.757] (--) evdev: USB Keyboard: Vendor 0x1241 Product 0x1503 [ 20.757] (--) evdev: USB Keyboard: Found keys [ 20.757] (II) evdev: USB Keyboard: Configuring as keyboard [ 20.757] (**) Option "config_info" "udev:/sys/devices/platform/sw-ohci.2/usb5/5-1/5-1:1.1/input/input3/event3" [ 20.757] (II) XINPUT: Adding extended input device " USB Keyboard" (type: KEYBOARD, id 9) [ 20.758] (**) Option "xkb_rules" "evdev" [ 20.758] (**) Option "xkb_model" "pc105" [ 20.758] (**) Option "xkb_layout" "us" Did you have some advice or solution ? Thanks a lot ! Fox

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)

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

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

First steps with LeMaker's guitar: These days a few SBC appear that are based on Actions Semi's S500 SoC (quad core Cortex A9r4 processor with 512KB L2 Cache and a PowerVR SGX544 GPU). Two competitors share the Raspberry's form factor (they both use Actions Semi's reference design): Lemon Pi: Roseapple Pi: The Allo SPARKY is also compatible to RPi HATs LeMaker's Guitar differs in size and shape(s) since the Guitar is the combination of one core board as SO-DIMM containing SoC, DRAM and the power management unit (PMU) and a few base boards featuring different hardware: (yes, currently you won't see a product picture since the LeMaker guys seem to like broken links -- they also start every few weeks to destroy every working link between their support forum and their wiki but since noone cares... I don't care too) All boards share the same common 40 pin GPIO header known from RPi A+/B+/2 and hardware characteristics due to using the same SoC/PMU: 2 USB 2.0 ports, 1 x USB 3.0, 1 or 2 GByte DRAM, up to 64 GByte Micro-SD-card, (optional) eMMC, HDMI output, MIPI DSI/CSI connectors for LCDs and cameras and a 'native' 10/100 MBit/sek Ethernet implementation. And they also share the same software limitations: Actions Semi provides only a weird 'SDK' containing a bunch of scripts and outdated heavily patched 3.10.37 kernel sources and there is zero efforts to get Actions Semi's SoCs supported by mainline kernel (which is really bad -- Amlogic/Hardkernel show with their kernel 3.10.y branch how it should work instead: you clone the official kernel tree, get a huge patchset from the SoC's manufacturer and can then merge all official patches in your customized kernel tree). Actions Semi now seems to be there where Allwinner was back in 2012 regarding 'openness' How differs the Guitar from the other boards: The coreboard/baseboard concept should theoretically help developing baseboards that suit ones needs. But since LeMaker hardware isn't Open-source hardware (OSH) I doubt we will anytime soon see baseboards from other manufacturers than LeMaker They use a different power scheme. The base board can be fed with 5-12V @ 2A which will then be used to power USB peripherals (somehow proprietary and not acting as charging downstream ports (CDP) in conformance with the USB Battery Charging Specification) and also the voltage will be converted down to 4.28V to feed the PMU which then creates the different voltages the board's core components need. According to LeMaker they're able to supply additional 3.1A@5V on the USB ports. For details see below USB 3: According to LeMaker they couldn't use the usual blue Type A port to easily connect peripherals like disks, Ethernet adapters or USB3 hubs but had chose the Micro-B port instead since this port can automagically determine whether to operate in host or device mode (obviously they believe people do flash way more often the onboard eMMC than trying to connect USB peripherals). For reasons yet unknown to me the Micro-B port LeMaker used is incompatible with certain (most?) USB3 cables. To sum it up: USB3 isn't useable unless you're lucky enough to find an adapter cable to interconnect the Guitar with normal USB peripherals. Update: These cables do not exist and you have to customize a cable to get USB3 support with LeMaker's Guitar. Unbelievable! Since I'm neither interested in Android (should work flawlessly since Actions Semi's SoCs originate from this environment) nor in Linux as a desktop nor in GPIO stuff (should just work but unfortunately LeMaker chose wider spaces between the mounting holes which has consequences for HATs -- see below) I focused on the basics (getting any information about S500 and the board's hard- and software) and the area I'm interested in: low-power servers that act partially as a NAS. Therefore you won't find any words on GPU/VPU performance/acceleration or classical SBC/IoT stuff like interacting with sensors and stuff like that. I did some tests regarding integer performance with the default 1.1 GHz and also with 1.3 GHz using an own kernel build (you have to adjust operating points in the kernel's cpufreq sources to define clock speeds and Vcore voltage accordingly). With 1.3 GHz the S500 is the fastest quad core SoC I tested so far. But unless you use a fan I wouldn't recommend running at this speed since both SoC and PMU get freaking hot and when thermal throttling jumps in after a few minutes the performance drops drastically. Without a fan you can operate the device only short periods of time with 1.3 GHz and then it either starts to overheat or to throttle down (for yet unknown reasons throttling sometimes failed in my tests and I managed to trigger emergency shutdowns at 125°C throttling is now fixed). Therefore I used the 1.1 GHz setting for the tests. The other 4 boards I compared with were also clocked at reasonable speeds: Raspberry Pi 2, BroadCom BCM2836 quad core SoC, 1.0 GHz Hardkernel ODROID-C1+, Amlogic S805 quad core SoC, 1.7 GHz Wandboard Quad, Freescale i.MX6 quad core SoC, 1.0 GHz not yet released SBC with Allwinner's A20 quad core successor, 1.1 GHz (tests done with Banana Pi @ 960 MHz and interpolated to 1.1 GHz and 4 CPU cores) The board performs nicely in this area (same applies to sequential transfer speeds to/from SD card or eMMC) but for my use cases I/O and network performance are way more important. Due to LeMaker's choice to introduce mechanical incompabilities that prevent using USB 3.0 for this purpose I will stop at the moment. The USB 2.0 performance is bad (caused by the outdated 3.10.37 kernel we have to use with the S500 that doesn't feature UAS or btrfs support and does not contain USB/ext4 fixes and maybe also caused by Actions Semi's USB implementation) and WiFi or 10/100 Mbits/sec aren't worth to measure since other SoCs feature native GBit Ethernet. Therefore I will stop testing the Guitar unless LeMaker designs a baseboard that makes USB3 useable (featuring the normal Type A port and ideally containing an USB hub and both an UAS capable USB-to-SATA bridge like JMicron's JMS567 and an Ethernet adapter like the ASIX AX88179) and wait for Allwinner's next quad core baby that features both native SATA and GBit Ethernet It's too early to draw conclusions and my use case is obviously too specific for the Guitar. Unfortunately it was rather hard work to get/collect all the informations below and still many questions are open. Time will tell whether they'll be answered by LeMaker and Actions Semi and whether the software side evolves. With the current outdated 3.10.37 kernel the S500 is cut off from important stuff like mature kernel code for modern filesystems and tons of fixes inside the kernel (bug and/or security fixes) Original Thread starting one week ago: Today I received my Guitar (well done since it shipped at the end of last week in Shenzen and has been delivered an hour ago in Munich!). I connected it via HDMI to a display, via Ethernet to a network with DHCP server and via a simple 5V/2A PSU to wall power. The Guitar comes with 1 GByte DDR3 RAM and a quad core SoC. (Partially misleading/wrong) informations here: http://wiki.lemaker.org/LeMaker_Guitar Boot time below 30 seconds. Consumption peak at 3.5W while booting and 2.7W when idling with X server running. Both the SoC (thermal_zone1) as well as the ATC2603 PMU expose internal thermal sensors: /sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-hwmon.0/ic_temperature: 49822 mCel /sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-power.0/power_supply/battery/temp: 0 /sys/devices/virtual/thermal/thermal_zone1/temp: 60000 The PMU can be queried (and maybe its behaviour also modified) using I2C: root@Lemuntu:/sys/devices/b0170000.i2c/i2c-0/0-0065# ls -al total 0 drwxr-xr-x 29 root root 0 Jan 1 2011 . drwxr-xr-x 4 root root 0 Jan 1 2011 .. drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-adckeypad.0 drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-audio.0 drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-cap-gauge.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-dcdc1.1 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-dcdc2.2 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-dcdc3.3 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ext-pwm-dcdc1.1 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ext-pwm-dcdc2.2 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-gpio.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-hwmon.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-irkeypad.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo1.1 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo11.11 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo2.2 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo3.3 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo5.5 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo6.6 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo7.7 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo8.8 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-onoff.0 drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-pm.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-power.0 drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-pwm.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-rtc.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-sgpio.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-switch1.1 -r--r--r-- 1 root root 4096 Oct 5 14:26 auxadc_dbg lrwxrwxrwx 1 root root 0 Jan 1 2011 driver -> ../../../../bus/i2c/drivers/atc260x_i2c -r--r--r-- 1 root root 4096 Oct 5 14:26 modalias -r--r--r-- 1 root root 4096 Jan 1 2011 name drwxr-xr-x 2 root root 0 Oct 5 14:11 power -r--r--r-- 1 root root 4096 Oct 5 14:26 pstore_dbg -rw-r--r-- 1 root root 4096 Oct 5 14:26 reg_dbg lrwxrwxrwx 1 root root 0 Jan 1 2011 subsystem -> ../../../../bus/i2c -rw-r--r-- 1 root root 4096 Jan 1 2011 uevent root@Lemuntu:/sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-dcdc1.1/regulator/regulator.1# ls -al total 0 drwxr-xr-x 3 root root 0 Jan 1 2011 . drwxr-xr-x 3 root root 0 Jan 1 2011 .. -r--r--r-- 1 root root 4096 Oct 5 14:27 bypass lrwxrwxrwx 1 root root 0 Oct 5 14:27 cpu0-cpuvdd -> ../../../../../../system/cpu/cpu0 lrwxrwxrwx 1 root root 0 Oct 5 14:27 device -> ../../../atc2603c-dcdc1.1 -r--r--r-- 1 root root 4096 Oct 5 14:27 max_microvolts -r--r--r-- 1 root root 4096 Oct 5 14:27 microvolts -r--r--r-- 1 root root 4096 Oct 5 14:27 min_microvolts -r--r--r-- 1 root root 4096 Oct 5 14:27 name -r--r--r-- 1 root root 4096 Oct 5 14:27 num_users drwxr-xr-x 2 root root 0 Oct 5 14:11 power -r--r--r-- 1 root root 4096 Oct 5 14:27 state -r--r--r-- 1 root root 4096 Oct 5 14:27 status lrwxrwxrwx 1 root root 0 Oct 5 14:27 subsystem -> ../../../../../../../class/regulator -r--r--r-- 1 root root 4096 Oct 5 14:27 suspend_disk_state -r--r--r-- 1 root root 4096 Oct 5 14:27 suspend_mem_state -r--r--r-- 1 root root 4096 Oct 5 14:27 suspend_standby_state -r--r--r-- 1 root root 4096 Oct 5 14:27 type -rw-r--r-- 1 root root 4096 Jan 1 2011 uevent Kernel config: http://pastebin.com/9bUSA7Rr For whatever reasons the device is not able to run at 1.3Ghz as advertised (UPDATE: I managed to clock it with 1.3 GHz by modifying kernel sources and building the kernel on my own -- see a few posts below): root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_available_frequencies 408000 720000 900000 1104000 root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_available_governors conservative ondemand userspace powersave interactive performance root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_cur_freq 408000 root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# echo performance >scaling_governor root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# echo 1104000 >scaling_max_freq root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_cur_freq 1104000 Clocked with 1.1Ghz it reaches 2338 7-zip benchmark points -- compare with https://s1.hoffart.de/7zip-bench/ "sysbench --test=cpu --cpu-max-prime=5000 run --num-threads=4" finishes in 19.5 seconds. Regarding integer/memory performance in these two short tests the Guitar is roughly 2.3 times faster at this clock speed compared to an A20 based device with the same clock speed: http://linux-sunxi.org/Category:A20_Boards Disclaimer: It's not clear whether memory performance improves if one disables GPU stuff (like it's the case with slow Allwinner SoCs where high display resolution/colordepth/bandwidth decreases overall memory throughput) so this is just a rough estimate and not a benchmark at all. While running the sysbench test on all CPU cores the consumption increases by 3W and the reported temperature rise up to 76°C SoC and 57°C PMU (when idle in my setup with the Guitar operated vertically with enough airflow around: 60°C SoC and 50°C PMU, when set to ondemand governor and idling at just 408 MHz the temperatures decrease to 56°C SoC and 47°C PMU). Warning: These are just values read out using sysfs and not any real measurements. I collected some other informations at the link below (apply to Guitar Core Board v1.3 and Guitar Base Board Rev. B and "Lemuntu" V1509 (http://www.lemaker.org/article-64-1.html -- obviously LeMaker doesn't care about correct informations, the kernel version there is completely wrong) http://pastebin.com/ZpMNkbU1 Complete boot log via debug UART: http://pastebin.com/X2ppDEwS Device tree used: http://pastebin.com/QNb3i9F6 Contents of /boot/uEnv.txt: uenvcmd=setenv ramdisk_addr_r -; setenv os_type linux; bootargs=earlyprintk clk_ignore_unused selinux=0 scandelay root=/dev/mmcblk0p2 rw console=tty0 rootfstype=ext4 console=ttyS3 loglevel=4 rootwait If sometimes in the future an "SDK" will be released I believe it would be a nice board to add to Armbian? Any comments on that? UPDATE: In the meantime some docs/tools have been released and maybe a community evolves around Actions Semi's SoCs: S500 manual v1.4: http://mirror.lemaker.org/Datasheet_For_S500_V1.4.pdf ATC2603C manual v2.1: http://mirror.lemaker.org/Datasheet_For_ATC2603C_V2.1.pdf image-create-tools (to combine bootloader+kernel with rootfs): https://github.com/LeMaker/image-create-tools-actions bootloader+kernel (both not as source!) LeMaker uses: https://github.com/LeMaker/hwpack-s500 XApp-le community: http://wiki.linux-xapple.org/w/index.php/Main_Page

Thanks... I managed to build armbian "4.4" from your git sources. I did build the Ubuntu trusty with Kernel 4.2.1 (next) and desktop. Now when starting the X (startx) I get a segmentation fault: root@udoo:~# cat /var/log/Xorg.0.log [ 378.989] X.Org X Server 1.15.1 Release Date: 2014-04-13 [ 378.990] X Protocol Version 11, Revision 0 [ 378.990] Build Operating System: Linux 3.2.0-67-highbank armv7l Ubuntu [ 378.991] Current Operating System: Linux udoo 4.2.1-udoo #1 SMP Tue Sep 29 23:33:34 CEST 2015 armv7l [ 378.991] Kernel command line: root=/dev/mmcblk0p1 rootfstype=ext4 rootwait console=tty1 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 rd.dm=0 rd.luks=0 rd.lvm=0 raid=noautodetect pci=nomsi ahci_imx.hotplug=1 quiet [ 378.993] Build Date: 12 February 2015 02:55:07PM [ 378.993] xorg-server 2:1.15.1-0ubuntu2.7 (For technical support please see http://www.ubuntu.com/support) [ 378.993] Current version of pixman: 0.30.2 [ 378.994] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 378.995] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 378.997] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Sep 30 09:18:42 2015 [ 378.998] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 378.999] (==) No Layout section. Using the first Screen section. [ 378.999] (==) No screen section available. Using defaults. [ 378.999] (**) |-->Screen "Default Screen Section" (0) [ 378.999] (**) | |-->Monitor "<default monitor>" [ 379.000] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 379.000] (==) Automatically adding devices [ 379.000] (==) Automatically enabling devices [ 379.000] (==) Automatically adding GPU devices [ 379.000] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 379.000] Entry deleted from font path. [ 379.000] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist. [ 379.000] Entry deleted from font path. [ 379.000] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist. [ 379.000] Entry deleted from font path. [ 379.000] (WW) The directory "/usr/share/fonts/X11/Type1" does not exist. [ 379.001] Entry deleted from font path. [ 379.001] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist. [ 379.001] Entry deleted from font path. [ 379.001] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist. [ 379.001] Entry deleted from font path. [ 379.001] (==) FontPath set to: /usr/share/fonts/X11/misc, built-ins [ 379.001] (==) ModulePath set to "/usr/lib/arm-linux-gnueabihf/xorg/extra-modules,/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules" [ 379.001] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 379.001] (II) Loader magic: 0x54c06f10 [ 379.001] (II) Module ABI versions: [ 379.001] X.Org ANSI C Emulation: 0.4 [ 379.001] X.Org Video Driver: 15.0 [ 379.001] X.Org XInput driver : 20.0 [ 379.001] X.Org Server Extension : 8.0 [ 379.002] (II) xfree86: Adding drm device (/dev/dri/card0) [ 379.002] (EE) [ 379.002] (EE) Backtrace: [ 379.003] (EE) [ 379.003] (EE) Segmentation fault at address 0x0 [ 379.004] (EE) Fatal server error: [ 379.004] (EE) Caught signal 11 (Segmentation fault). Server aborting[ 379.005] (EE) [ 379.006] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 379.008] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 379.008] (EE) root@udoo:~# Any idea ?

Hi, I thought I enabled backports by default and as I didn't find docker.io yesterday, I thought it did not exist. - Seems I was wrong, wo I will check later when back home ! Thanks for pointing the right direction !

Hello, I have been trying to compile a new kernel for UDOO Quad, using the site instruction and the default config modified (I only added not removed), I succeded but, the new options were not included in the new kernel. I was trying to compile the new kernel with iptables nat support (Netfilter), but It seems that the new options were not included in the new compiled kernel. I am trying to build a VPN server, but I can't using the default kernel for UDOO quad. Can you please include in the standard release of UDOO quad (Vanilla) kernel support for VPN (netfilter). I always receive this error: "iptables v1.4.21: can't initialize iptables table 'nat': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded." Thank you very much. You did a very great job with UDOO Quad distros !!! Chris

Nand-sata-install asks for /dev/nand2 device, what does not exist, and until that, tool stucks (Edit: should script create it? Cuz it doesnt..). On a fresh a20 cubie, there is only /dev/nand. That is the reason why i used fdisk - to create /dev/nand2. Have PhoenixSuit 1.10 from sunxi, what reports, there is no attached device. Dont know its reason, either tool is wrong, or i found a broken board (?). Actually i dont know about any tool what can help me to test device usb port on cubie, so i have only ethernet connection this time.

Not in any case. You could also do some redirect/filter magic and let the output of a specific command lead to different triggers that modify blink frequency based on load or something like that. On page 4 of this thread there are many examples using iostat (one line in /etc/rc.local). Also the BananaLEDd project that has been started in the aforementioned thread should be usable starting with v1.2 on Cubietruck using the LED=cubietruck:orange:usr syntax. A simple daemon approach would be something like this (saved as eg. /usr/local/bin/diskblink.sh and started from within /etc/rc.local): #!/bin/bash export PATH=/usr/local/bin:/usr/bin:/bin MyLed="/sys/class/leds/green:ph24:led1" PartitionUUID=a7747356-feed-432a-81a3-7caea67c8cb8 PartitionDevice=$(ls -l /dev/disk/by-uuid/${PartitionUUID} | awk -F"/" '{print $7}') echo timer >${MyLed}/trigger while true ; do PartitionUseage=$(df -k | awk -F" " "/\/dev\/${PartitionDevice}/ {print \$5}" | tr -d '%') echo ${PartitionUseage} >${MyLed}/delay_on echo $(( ( 100 - ${PartitionUseage} ) * 100 )) >${MyLed}/delay_off # echo $(( 10000 - ${PartitionUseage} * ${PartitionUseage} )) >${MyLed}/delay_off sleep 10 done Since LED blinking is rather annoying I would also adjust brightness in the loop by something like this (value is in the range 0-255, with the following formula you get 2 with 10%, 62 with 50%, 202 with 90% and 245 with 99% -- so you will notice the LED only when it gets critical): echo $(( ${PartitionUseage} * ${PartitionUseage} / 40 )) >${MyLed}/brightness You've to define $MyLed and of course $PartitionUUID (lookup with blkid). The script uses the timer trigger and adjust on/off cycles based on df's percentage output for the partition in question. @Igor: Request for enhancement: please add BananaLEDd to /usr/local/bin for the A20 boards and ship with a disabled config for all supported boards :-)

This address does not exist in my ubuntu ct distribution. Although there is /sys/class/leds/orange\:ph20\:led2/trigger This file have a sintax like a b [c] d, to enable trigger c. The issue is that this file can not be writen in any way. Is this config somewhere else?

I've been looking for a way to rotate the display and change the resolution on the Hummingboard running the Debian image I did this from the FAQ: screen resolution: nano /boot/boot.cmd # example: # change example from # disp.screen0_output_mode=1920x1080p60 # to # disp.screen0_output_mode=1280x720p60 mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr somewhat blindly and I destroyed the boot.scr, further searching found that /boot/boot.cmd doesn't exist... I've been messing with xorg with no avail. I think that this is the way to do, through the boot.scr, but there is not any good way to get that running.. The larger question, I guess, is what is the most effective way to rotate the display and change the resolution?

Given the positions of the other openings I really doubt that a few holes on top are sufficient. If you're using 3.4.x kernel you can at least read out the temperature values of SoC and PMU. Store this code here eg. as /usr/local/bin/gettemp.sh and do a source /usr/local/bin/gettemp.sh pmutemp soctemp afterwards (it might be necessary to become root and soctemp sometimes works only if you called it a couple of times). I found that reading out temperatures in mainline is way more difficult/wrong: With kernel 4.x you can query the SoC's temperature sensor using /sys/devices/virtual/thermal/thermal_zone0/temp but the values provided are slightly off in 4.0 and completely messed up in 4.1.x Sysfs/I2C integration for the PMU is gone in mainline and while there exist patches (see the end of this page http://sunxi.montjoie.ovh) it's obvious that the values measured are wrong (this was the same with the SoC's temp patches from the same author with kernel 3.4 -- also wrong values without further adjustment): SoC's temperature +40.6°C and PMU's just 23.5°C --> nearly impossible. When I made some extensive tests half a year ago I realized that the IC's temperature is always at least 10°C above ambient (10°/7°C when using an efficient SMD heatsink) and that it's nearly impossible to create a workload on the CPU cores that leads to the SoC's temp being 17°C exceeding the PMU's.

I have forked your repo to add a lot of media server stuff, I added syncthing too with the code below install_syncthing () { #-------------------------------------------------------------------------------------------------------------------------------- # Install syncthing #-------------------------------------------------------------------------------------------------------------------------------- SYNCTHINGUSER=$(whiptail --inputbox "Enter the user to run Syncthing as (usually pi)" 8 78 $SYNCTHINGUSER --title "$SECTION" 3>&1 1>&2 2>&3) exitstatus=$?; if [ $exitstatus = 1 ]; then exit 1; fi if ! getent passwd $SYNCTHINGUSER > /dev/null; then echo "User $SYNCTHINGUSER doesn't exist, exiting, restart the installer" exit fi if !(cat /etc/apt/sources.list.d/syncthing-release.list | grep -q Syncthing > /dev/null);then cat >> /etc/apt/sources.list.d/syncthing-release.list <<EOF # Syncthing deb http://apt.syncthing.net/ syncthing release EOF wget -O - https://syncthing.net/release-key.txt | apt-key add - debconf-apt-progress -- apt-get update debconf-apt-progress -- apt-get install syncthing -y sudo -u $SYNCTHINGUSER timeout 120s syncthing #Make syncthing webui remotely accessible sed -i "/ <address>127.0.0.1:8384/c\ \<address>0.0.0.0:8384\<\/address\>" /home/$SYNCTHINGUSER/.config/syncthing/config.xml cd /etc/init.d/ wget https://raw.github.com/blindpet/MediaServerInstaller/usenet/scripts/syncthing sed -i "/DAEMON_USER=root/c\DAEMON_USER=$SYNCTHINGUSER" /etc/init.d/syncthing chmod +x /etc/init.d/syncthing cd /tmp update-rc.d syncthing defaults service syncthing start echo Syncthing is running on $showip:8384 fi } I also changed btsync so it uses a repo and makes it much easier cd /tmp wget http://debian.yeasoft.net/add-btsync-repository.sh ( echo yes && \ echo yes ) \ | sh add-btsync-repository.sh apt-get update apt-get install btsync -y I haven't ever made a pull request but will try sometime next month

Haha, I am using "CUSTOM_KERNEL_CONFIG" for a while now in my edited script, but it need more testing and I need to add comments before making pull request... Simply, my script does not load default .config when CUSTOM_KERNEL_CONFIG is set to "yes" AND .config exist in kernel directory. It does not have the ability to change path to .config.

You need to use one of the exiting tags. https://github.com/patrykk/linux-udoo Go to branch, select TAGS and you'll see what are possible tags. v3.18.3 does not exist, but v3.18.13, v4.0.0., .. If setting doesn't work trough my script, do it manually. I can check / fix later in the evening / tomorrow morning. Cheers.

I now connected a ssd drive to my cubietruck. with ls /dev/ | grep sd I got sda, but when I try to format this drive with mkfs.ext4 /dev/sda1 I get this errormessage: Could not stat /dev/sda1 --- No such file or directory The device apparently does not exist; did you specify it correctly? How can I format the ssd ?

Do you asking me about my compilation of your brand or ct-dvk brand? I checked both again: Your config from /lib/config/cubietruck.fex: [twi_para] twi_port = 0 twi_scl = port:PB0<2><default><default><default> twi_sda = port:PB1<2><default><default><default> ;------------------------------------------------------------------------------- ;i2c configuration ;------------------------------------------------------------------------------- [twi0_para] twi0_used = 1 twi0_scl = port:PB0<2><default><default><default> twi0_sda = port:PB1<2><default><default><default> [twi1_para] twi1_used = 0 twi1_scl = port:PB18<2><default><default><default> twi1_sda = port:PB19<2><default><default><default> [twi2_para] twi2_used = 0 twi2_scl = port:PB20<2><default><default><default> twi2_sda = port:PB21<2><default><default><default> config from ct-dkv distro /boot/script.fex: [twi_para] twi_port = 0 twi_scl = port:PB0<2><default><default><default> twi_sda = port:PB1<2><default><default><default> ;------------------------------------------------------------------------------- ;i2c configuration ;------------------------------------------------------------------------------- [twi0_para] twi0_used = 1 twi0_scl = port:PB0<2><default><default><default> twi0_sda = port:PB1<2><default><default><default> [twi1_para] twi1_used = 1 twi1_scl = port:PB18<2><default><default><default> twi1_sda = port:PB19<2><default><default><default> [twi2_para] twi2_used = 1 twi2_scl = port:PB20<2><default><default><default> twi2_sda = port:PB21<2><default><default><default> Now I see that into your config we have disabled twi1_used and twi2_used parameters ... ... so maybe enable it is necessary to proper work :-) I'll make new compilation and I'll try confirm my idea. (or at first i change script.bin/fex into exist distro) BTW, I've permanently connected 1 thing (i2c sd1306 display) for test:

Hi! I'm trying to use the image Cubietruck_Debian_3.8_jessie_4.0.4.raw with my CubieTruck, but run into problems when trying to use an external LUKS-disk which is encrypted using aes-xts-plain64. 'cryptsetup luksOpen' informs the following: device-mapper: reload ioctl on failed: No such file or directory Failed to setup dm-crypt key mapping for device /dev/disk/by-uuid/<xxxx>. Check that kernel supports aes-xts-plain64 cipher (check syslog for more info). 'cat /proc/crypto | grep name' lists only this, which seems kinda minimal: name : stdrng name : stdrng name : crc32c name : deflate name : ecb(arc4) name : arc4 name : aes name : des3_ede name : des name : sha224 name : sha256 name : sha1 name : md5 name : md4 Directory /lib/modules/4.0.4-cubietruck/kernel/crypto/ has these files: af_alg.ko algif_rng.ko async_tx ccm.ko crypto_null.ko ctr.ko fcrypt.ko gcm.ko gf128mul.ko ghash-generic.ko pcbc.ko seqiv.ko So, it seems that some crypto modules for the kernel are missing, but I don't know which ones are needed ('aes-xts' or similar, at least, maybe?). Any ideas on what to do? Do I need to compile the kernel to include the modules? Does the older 3.4.x(?) kernel have these included? Thanks.

I just wanted to confirm using your Banana Pi build script, I changed kernel to 3.19.7 and branch to next, modular PMP was enabled by default. It was as simple as adding options ahci-sunxi enable_pmp=1 to /etc/modprobe.d/ahci-sunxi.conf root@bananapi:~# blkid /dev/mmcblk0p1: UUID="a73fb24c-de15-4a1f-a4fe-b6436f8d98f3" TYPE="ext4" /dev/sda1: LABEL="SP PHD U3" UUID="190D-153C" TYPE="vfat" /dev/sdb1: LABEL="SP PHD U3" UUID="1917-2940" TYPE="vfat" /dev/sdc1: LABEL="SP PHD U3" UUID="19E3-1C09" TYPE="vfat" /dev/sdd1: LABEL="SP PHD U3" UUID="1911-0E2F" TYPE="vfat" Will release an image later with some media server tools installed The next step will be to have dvb support added