Search the Community

Hi! Thanks again for your comments zador. My tune2fs output on the nand system (armbian 3.8 on NAND) is: root@siamserver:~# tune2fs -l /dev/nand2 tune2fs 1.42.5 (29-Jul-2012) Filesystem volume name: <none> Last mounted on: / Filesystem UUID: 31cdf62b-f9d8-4571-8df8-5d7be293b5e7 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: unsigned_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 241440 Block count: 964608 Reserved block count: 48230 Free blocks: 218388 Free inodes: 159688 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 235 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8048 Inode blocks per group: 503 Flex block group size: 16 Filesystem created: Fri Oct 30 11:50:19 2015 Last mount time: Thu Dec 31 22:00:06 2009 Last write time: Thu Dec 31 22:00:06 2009 Mount count: 13 Maximum mount count: -1 Last checked: Fri Oct 30 11:50:19 2015 Check interval: 0 (<none>) Lifetime writes: 5808 MB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 90bab9a4-3bb6-4584-a0b9-3c041c01265c Journal backup: inode blocks On the SD card system (data partition on armbian 4.7 legacy kernel): root@siamserver(ro):~# tune2fs -l /dev/mmcblk0p2 tune2fs 1.42.12 (29-Aug-2014) Filesystem volume name: siamdb Last mounted on: /data Filesystem UUID: d1d3e3fd-3861-45ab-a3f5-a746df6b1681 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 256512 Block count: 1048576 Reserved block count: 52428 Free blocks: 683870 Free inodes: 247434 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 281 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8016 Inode blocks per group: 501 Flex block group size: 16 Filesystem created: Tue Dec 8 09:24:13 2015 Last mount time: Fri Dec 18 18:29:27 2015 Last write time: Fri Dec 18 18:29:27 2015 Mount count: 839 Maximum mount count: -1 Last checked: Fri Dec 11 17:10:32 2015 Check interval: 0 (<none>) Lifetime writes: 1554 MB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 4efda314-91f3-4745-b9ee-1893be445276 Journal backup: inode blocks I think both have journal enabled, so this won't explain the problem either - or am I missing something! regards

The only feature that's interesting on the Raspberry Pi is that one can use the VPU correctly now (after a few years). We use RPi B+ as IP camera (even when the CPU core is clocked with just 200 MHz the VPU is able to provide a 1080p@30 fps h.264 encoded video stream) or for digital signage, often combined. In the meantime also lightweight distros exist like http://dietpi.com For everything else the RPi is always the worst choice due to its one single USB 2.0 connection to the outside. Supporting the RPi would mean Armbian either focuses on a completely new use case (desktop stuff -- VPU) or on a completely new user base (clueless people).

It's possible to both overvolt the CPU and undervolt the board These are two different things. You define in the so called dvfs table a few operating points with a relationship between CPU clockspeed and voltage provided to the CPU cores. The basic principle is that you define the Vcore voltage as low as possible since this helps with consumption, temperatures and longevity. But the problem is that if you need higher clockspeeds you also have to increase the Vcore voltage to still let the chip run reliably. There exist some recommended values from Allwinner for every SoC ("Vcore not lower than 1.04V and not higher than 1.2V for example") and responsible vendors follow these advices. Most H3 devices (OTT boxes) come with a dvfs table only containing 2 operating points: 1200 MHz @ 1.3V 1008 MHz @ 1.2V This is OK and leads to a Vcore voltage of 1.3V when clocked at 1008 MHz or above and 1.2V when running slower (most devices are configured to clock lower when idle and to increase clockspeeds only under full load -- and only then Vcore increases also). Xunlong then simply stayed with 2 operating points and increased both cpufreq and Vcore voltage (necessary to reach the 1.53 GHz they advertise as "1.6 GHz"): 1536 MHz @ 1.5V 1200 MHz @ 1.3V That means the H3 is always volted with the maximum all other devices use (1.3V) and if clockspeeds exceed 1200 MHz even with 1.5V (0.1V above the recommended upper limit). And this overvolting is the root cause for all the thermal problems Orange Pi users experienced in the past. I tried to document the overvolting/overclocking history here. Regarding DC-IN it's something different. There you should supply 5V but since many USB cables are simply crap and micro USB has very tiny contacts you might run in undervoltage situations easily (DC-IN dropping below 4.6V or even lower). SoCs that are accompanied by a PMIC/PMU will be powered-off in such a situation by the PMU to prevent damage. The Orange Pi PC has no PMU but a few voltage regulators that might work even with 4.5V. But for connected USB peripherals or HDMI this is already way too low. Therefor the barrel plug the Orange Pi's are equipped with is an advantage compared to boards that use [micro] USB since you've to consider that DC-IN also has to provide power to external USB devices and other board components. And as you can see above it always depends. When you want to use the Orange Pi PC just as a headless server and let it run at 1.2 GHz with a sane dvfs table the whole board's consumption won't exceed 3.5W so 5V/1A would already be enough. In case you attach 4 bus-powered USB drives even 5V/3A won't suffice (you would've to study the schematics or simply try it out to get a clue where the limits are)

Have you try this way: root=UUID=e139ce78-9841-40fe-8823-96a304a09859 I'll recreate similar scenario later just to make sure.

Hi, I tried UUID and PARTUUID but none of them works. Maybe this is a U-BOOT issue. root@cubietruck:/home/lampra# grep -a --null-data U-Boot /dev/mmcblk0 U-Boot U-Boot SPL 2015.07-armbian-sun7i (Oct 11 2015 - 15:34:22) I will post a question at the sunxi irc

Try to set desired root by it's UUID. It should work. https://help.ubuntu.com/community/UsingUUID edit /boot/boot.cmd and change parameter root= , save, recompile, reboot.

Another update regarding software / OS images. In the meantime they released a few more images: http://www.banana-pi.org/download.html As usual without MD5/SHA1 checksums so you can not check whether your download is corrupted or not. But even if they would provide checksums it won't help since SinoVoip simply doesn't give a sh*t about anything other than selling hardware. Numerous downloads are corrupted (see here or here or here) and they simply don't react even if customers complain multiple times. At the moment they are also clueless how to flash a Linux image onto eMMC using FEL mode (this only works with the Android images using PhoenixSuit/LiveSuit) so in case you want to start a Linux image from the internal eMMC storage you would have to first flash it to an SD card, then boot from this card, then transfer the image using dd to /dev/mmcblk1. I did it through the network as follows: ssh tk@macbookpro-tk "dd if=/Users/tk/Downloads/ubuntu-mate-15.10-desktop-armhf-raspberry-pi-2-bpi-m3-sd-emmc-20151203.img bs=4m" | dd of=/dev/mmcblk1 Three times dd quit unexpectedly while writing to eMMC, then I simply lowered the maximum cpufrequency down to 1008 MHz and it worked. Seems there's a bug when writing to eMMC so be prepared to experience filesystem corruptions if you're booting from eMMC. At least you can use eMMC this way, the M3 boots from there when no SD card is present. I tried then their Ubuntu 15.10 image and had a laugh: They ship with enabled irqbalanced! It's a well known fact that irqbalancing doesn't work on ARM based SBCs and has a memory leak on platforms that lack PCI/PCIe. So be prepared that irqbalanced will eat up all your RAM over time and then the whole system has to be rebooted. It's completely weird to release an OS image for an ARM SBC with an enabled irqbalanced. Now they ship also with a small script called bpi-bootsel (source here) which can be used to overwrite the 1st sectors of the boot media to change the display resolution (all their images based on Allwinner's 3.3/3.4 kernel for Banana Pi M2/M3 still lack support for script.bin!). In /usr/lib/u-boot/bananapi/ there exist 2 subdirs with a few handpicked archives to provide a few display configurations (details here). And while this is a small step in the right direction it also means they do it still wrong since they're continually fixing critical bugs for the M3 that should also be applied to the 1st sectors (there's where u-boot, hardware initialisation and a kernel image lives -- don't expect this stuff being easily accessible in /boot/). In other words: The new OS images they provide now are already outdated and cut-off from important fixes they commit in the meantime to their BSP github repo. Just a few words regarding the BSP: The initial Readme.md was just wrongly copy&paste from the Banana Pi M2 and of course misses the most important information: How to setup a build environment (details here). Back to the OS images. I dropped Ubuntu 15.10 since I already have my own image upgraded (apt-get install update-manager-core && do-release-upgrade sometimes works as expected ). Then I tried their so called "Armbian 4.7" image: It's the same outdated u-boot/kernel stuff missing the last fixes combined with a crippled Armbian rootfs. Of course nearly all Armbian features don't work and it's not worth the time to further explore this crap. They did not even adjust the thermal read-outs or prevent kernel messages from spamming to console as it will happen from time to time when thermal throttling occurs -- see their own image below. It seems it's as with the M2 half a year ago and as a Banana Pi M3 user you'll have to wait until the community jumps in and provides OS images that aren't that crappy. Close to unbelievable but unfortunately true.

dmesg | grep usb [ 0.399281] usbcore: registered new interface driver usbfs [ 0.403635] usbcore: registered new interface driver hub [ 0.407825] usbcore: registered new device driver usb [ 0.442458] [usb_manager]: CONFIG_USB_SW_SUNXI_USB0_OTG [ 0.446259] [sw_hcd0]: usb host driver initialize........ [ 0.450484] [sw_hcd0]: open_usb_clock [ 0.475713] [sw_hcd0]: platform is usb host [ 0.520661] [sw_hcd0]: sw_usb_host0_disable start [ 0.537521] [sw_hcd0]: close_usb_clock [ 0.539983] [sw_hcd0]: sw_usb_host0_disable end [ 1.465566] usbcore: registered new interface driver usb-storage [ 1.474093] usbcore: registered new interface driver ums-alauda [ 1.479090] usbcore: registered new interface driver ums-cypress [ 1.486738] usbcore: registered new interface driver ums-datafab [ 1.491930] usbcore: registered new interface driver ums_eneub6250 [ 1.496925] usbcore: registered new interface driver ums-freecom [ 1.501851] usbcore: registered new interface driver ums-isd200 [ 1.506932] usbcore: registered new interface driver ums-jumpshot [ 1.511784] usbcore: registered new interface driver ums-karma [ 1.516867] usbcore: registered new interface driver ums-onetouch [ 1.521892] usbcore: registered new interface driver ums-realtek [ 1.526804] usbcore: registered new interface driver ums-sddr09 [ 1.531731] usbcore: registered new interface driver ums-sddr55 [ 1.536553] usbcore: registered new interface driver ums-usbat [ 1.821906] usb 3-1: new full-speed USB device number 2 using sw-ohci [ 1.827147] usbcore: registered new interface driver usbhid [ 1.830028] usbhid: USB HID core driver [ 2.191211] usb 4-1: new high-speed USB device number 2 using sw-ehci [ 2.621450] usb 4-1.1: new high-speed USB device number 3 using sw-ehci [ 2.769636] scsi1 : usb-storage 4-1.1:1.0 [ 2.871453] usb 4-1.2: new full-speed USB device number 4 using sw-ehci [ 3.101461] usb 4-1.3: new full-speed USB device number 5 using sw-ehci [ 4.990008] usbcore: registered new interface driver usbserial [ 5.000132] usbcore: registered new interface driver usbserial_generic [ 5.008092] usbserial: USB Serial Driver core [ 5.031642] usbcore: registered new interface driver ftdi_sio [ 5.102168] usb 3-1: Detected FT232RL [ 5.133077] usb 3-1: Number of endpoints 2 [ 5.168007] usb 3-1: Endpoint 1 MaxPacketSize 64 [ 5.191657] usb 3-1: Endpoint 2 MaxPacketSize 64 [ 5.220910] usb 3-1: Setting MaxPacketSize 64 [ 5.246835] usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0 [ 5.356697] usb 4-1.2: Detected FT232RL [ 5.381334] usb 4-1.2: Number of endpoints 2 [ 5.389025] usb 4-1.2: Endpoint 1 MaxPacketSize 64 [ 5.394416] usb 4-1.2: Endpoint 2 MaxPacketSize 64 [ 5.399036] usb 4-1.2: Setting MaxPacketSize 64 [ 5.415289] usb 4-1.2: FTDI USB Serial Device converter now attached to ttyUSB1 [ 5.424796] usb 4-1.3: Detected FT232RL [ 5.428032] usb 4-1.3: Number of endpoints 2 [ 5.435922] usb 4-1.3: Endpoint 1 MaxPacketSize 64 [ 5.440169] usb 4-1.3: Endpoint 2 MaxPacketSize 64 [ 5.443777] usb 4-1.3: Setting MaxPacketSize 64 [ 5.464739] usb 4-1.3: FTDI USB Serial Device converter now attached to ttyUSB2 [ 1146.326270] usb 4-1: clear tt 1 (9041) error -110 [ 4057.151681] usb 4-1: clear tt 1 (9051) error -110 [14647.266733] usb 4-1: clear tt 1 (9041) error -110 [183851.069396] usb 4-1: USB disconnect, device number 2 [183851.073556] usb 4-1.1: USB disconnect, device number 3 [183851.084548] usb 4-1.2: USB disconnect, device number 4 [183851.105603] usb 4-1.3: USB disconnect, device number 5 [183886.688101] usb 4-1: new high-speed USB device number 6 using sw-ehci [183901.844742] usb 4-1: device descriptor read/64, error -110 [183917.112428] usb 4-1: device descriptor read/64, error -110 [183917.343435] usb 4-1: new high-speed USB device number 7 using sw-ehci [183932.861216] usb 5-1: new full-speed USB device number 2 using sw-ohci [183933.078461] usb 5-1: not running at top speed; connect to a high speed hub [183933.097990] scsi2 : usb-storage 5-1:1.0 [188674.645430] usb 5-1: USB disconnect, device number 2 lsusb Bus 003 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub uname -r Debian Wheezy 3.4.109-sun7i blkid /dev/sda1: UUID="f64f5613-ce08-49e9-b13a-356dcdcb1893" TYPE="ext4" /dev/mmcblk0p1: UUID="fbd8dfce-58fb-45a1-93d7-16895308a8d8" TYPE="ext4"

Можно, надо переÑобрать u-boot Ñ Ð¸Ð·Ð¼ÐµÐ½ÐµÐ½Ð½Ð¾Ð¹ конфигурацией и монтировать корневую Ñ„Ñ Ð¿Ð¾ uuid, иначе при уÑтановке карты во второй Ñлот вÑе поломаетÑÑ)

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

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?