Search the Community

Something like # if initrd.img for current version does not exist update-initramfs -c -k $(uname -r) # or if it does exist - update update-initramfs -u -k $(uname -r) # and then pack it to uInitrd mkimage -A arm -O linux -T ramdisk -C gzip -n uInitrd -d /boot/initrd.img-$(uname -r) /boot/uInitrd

Oh, you threw money at @sinovoip, realize now that there exist plenty of problems on the software side and expect us to fix that? For free? Really? Don't you think you should ask @sinovoip for a solution instead? Or at least ask them to pay us if you expect us fixing their issues?

I tried getting the wifi working a while back, but not a serious effort as I typically use a better performing USB Wi-Fi dongle. The main hurdle on the internal Wi-Fi was that the drivers exist in the sun7i but not the sun8i kernel. I was more interested in the eMMC, but didn't even know where to start.

@wildcat_paris Thanks for your update. I'm reading very interesting your link and motivated @Shuah for share her progress with the XU4 community. Update 13. Juni: I built the Kernel 4.7.0-rc2-next following the guides from @ummidelb and @shuah The main problem that I had is that the SD Card device numbering for mmcblk0 changed to mmcblk1 (probably NAND device is now mmclbk0?) and therefore it was necessary to use UUID in u-boot environment variables and in /etc/fstab. Moreover I had a Hardkernel Ubuntu Image wich had 3.10.84 updated by hardkernel scripts until 3.10.96 with Xenial. After that I put on the top the ARMBIAN Kernel 3.10.110. The u-boot environment variable had to be changed to the original one from Hardkernel: setenv bootrootfs "console=tty1 console=ttySAC2,115200n8 root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait ro fsck.repair=yes" ... ... setenv bootcmd "fatload mmc 0:1 0x40008000 zImage_next; fatload mmc 0:1 0x42000000 uInitrd-4.7.0-rc2-next-20160609; fatload mmc 0:1 0x44000000 exynos5422-odroidxu4_next.dtb; bootz 0x40008000 0x42000000 0x44000000" But because the HDMI is broken and no serial UART available atm (german reseller has no more and I didn't want to order once again from Korea..) it was difficult to debug when it was not booting. I enabled USB_CONFIG_UAS=y, but didn't work out the box. Probably patches are necessary, like other to fix the CPUs order, the ethernet which is attached to the USB2.0 instead of 5Gbps, etc.

Hi rella, I have a tvbox, but i always used the cubieboard2 stuff. The "some problems" also exist without fullscreen, all the stuff in the monitor (desktop and video surface) will have some movement. With https://github.com/l...43260738d33751d I also have the same result as your 'for_master_upstream' branch, it will show the video in the window but in fullscreen it will not resize the video. I also have the "some problems" with your 3 branchs (dev,master,for_upstream_master) of libvdpaud that I tested.

Ah I can at least get past this issue now - the compile.sh is missing the command to make the /debootstrap directory if it does not already exist.... Igor, that is a minor update which is required

It's really sad to see that the problem continues, I'm forced to stay in Armbian 5.10 to be able to use video playback. I will try to find to find the problem, but my knowledge maybe small for such task. EDIT: with system uptodate the problem still exist, if I decode a video by software it play fine, if I play with VDPAU the video will get dark. If I downgrade linux-image-sun7i (sudo apt-get install linux-image-sun7i=5.10) the VDPAU will work again without problem. May it be a kernel problem?

As a side note, I changed the hostname / fex (as explained by tkaiser) and tried to upgrade my 5.10 install. I got this error Setting up libdpkg-perl (1.17.27) ... Setting up dpkg-dev (1.17.27) ... Setting up initramfs-tools (0.120+deb8u2) ... update-initramfs: deferring update (trigger activated) Setting up linux-firmware-image-sun8i (5.13) ... Setting up linux-headers-sun8i (5.13) ... Compiling headers - please wait ... Setting up linux-image-sun8i (5.13) ... update-initramfs: Generating /boot/initrd.img-3.4.112-sun8i Setting up linux-jessie-root-nanopim1 (5.11) ... Setting up linux-u-boot-nanopim1-default (5.11) ... Setting up openssl (1.0.1t-1+deb8u2) ... Processing triggers for libc-bin (2.19-18+deb8u4) ... Processing triggers for systemd (215-17+deb8u4) ... Processing triggers for initramfs-tools (0.120+deb8u2) ... /boot/initrd.img-3.4.112-sun8i does not exist. Cannot update. root@nanopim1:~# ls /boot/ bin/ boot.scr uInitrd bin.old/ config-3.4.112-sun8i .verbose boot.bmp script.bin vmlinuz-3.4.112-sun8i boot.cmd System.map-3.4.112-sun8i zImage

This will be my last answer for now since you seem to ignore answers anyway. Please check your so called 'very high-quality SDCards' immediately and read through the 'SD card performance' thread I already recommended to you over there: http://forum.armbian.com/index.php/topic/1302-running-apt-get-dist-upgrade-installs-the-new-kernel-but-takes-the-orange-pi-pc-a-really-long-time/ Regarding led behaviour it's that easy. All the OS images over at orangepi forums use Allwinner's oudated u-boot 2011.09 (where the led will be powered on immediately) while we use mainline u-boot where the led gets activated later (the time span already increased a lot since most recent mainline u-boot version scans all USB busses for peripherals). Anyway: if Armbian boots slow then your SD card is most probably the culprit. And no, after doing some very extensive testing I don't believe in any marketing claims any more. Counterfeit cards exist, most SD cards used are slow as hell when it's about random IO. Again: Read from here on: http://forum.armbian.com/index.php/topic/954-sd-card-performance/

I try to compile again, try this time using x64 machine Got repository error this time Repo down? ----------------------------------------------------------------------------------------------------- fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. [ o.k. ] Starting Armbian build script [ @host ] [ o.k. ] Building [ Armbian 5.12 Bananapim2plus Debian jessie default ] [ o.k. ] Syncing clock [ host ] [ o.k. ] source downloading [ @host ] fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. [ o.k. ] ... creating a shallow clone [ u-boot ] Cloning into '/home/user/Armbian/sources/u-boot/v'... fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. /home/user/Armbian/lib/general.sh: line 162: cd: /home/user/Armbian/sources/u-boot/v: No such file or directory [ o.k. ] ... creating a shallow clone [ linux-sun8i sun8i ] Cloning into '/home/user/Armbian/sources/linux-sun8i/sun8i'... remote: Counting objects: 45250, done. remote: Compressing objects: 100% (40065/40065), done. remote: Total 45250 (delta 4576), reused 45249 (delta 4576), pack-reused 0 Receiving objects: 100% (45250/45250), 126.32 MiB | 1.40 MiB/s, done. Resolving deltas: 100% (4576/4576), done. Checking connectivity... done. [ o.k. ] ... creating a shallow clone [ sunxi-tools ] Cloning into '/home/user/Armbian/sources/sunxi-tools'... remote: Counting objects: 55, done. remote: Compressing objects: 100% (49/49), done. remote: Total 55 (delta 18), reused 27 (delta 5), pack-reused 0 Unpacking objects: 100% (55/55), done. Checking connectivity... done. [ o.k. ] ... creating a shallow clone [ sunxi-display-changer ] Cloning into '/home/user/Armbian/sources/sunxi-display-changer'... remote: Counting objects: 9, done. remote: Compressing objects: 100% (8/8), done. remote: Total 9 (delta 0), reused 7 (delta 0), pack-reused 0 Unpacking objects: 100% (9/9), done. Checking connectivity... done. [ o.k. ] Compiling sunxi tools [ @host & target ] [ o.k. ] Cleaning [ linux-sun8i/sun8i ] /home/user/Armbian/lib/main.sh: line 212: cd: /home/user/Armbian/sources/u-boot/v: No such file or directory cat: /home/user/Armbian/sources/u-boot/v/Makefile: No such file or directory cat: /home/user/Armbian/sources/u-boot/v/Makefile: No such file or directory cat: /home/user/Armbian/sources/u-boot/v/Makefile: No such file or directory cat: /home/user/Armbian/sources/u-boot/v/Makefile: No such file or directory [ o.k. ] Started patching process for [ u-boot u-boot-default ] [ o.k. ] Looking for user patches in [ userpatches/u-boot/u-boot-default ] [ o.k. ] ... add-awsom-uboot.patch [ succeeded ] [ o.k. ] ... add-cubieboard4.patch [ succeeded ] [ warn ] ... bananapi-enable-ldo4.patch [ failed ] [ warn ] ... u-boot-02-support-cheap-mmc.patch [ failed ] [ o.k. ] ... u-boot-99-add-missing-boards.patch [ succeeded ] [ error ] ERROR in function compile_uboot [ common.sh:29 ] [ error ] Error building u-boot: source directory does not exist [ u-boot/v ]

Hi again, I found great article about swap folow link below. But I must mention something important. Swap file does not contain any valuable information. So it has not sense to move it. We just delete old, create new one and change path if it is a file somewhere on filesystem or UUID if it is partition in fstab. I do prefer to create swap partition on the end of sdcard or microsd because even value on label of card says it is 8GB every brand has different capacity. And this difference can be sometimes more than 100MB. So I decided to shrink root partition to 7.5GB and rest of capacity is swap partition. When I need to clone whole microsd I delete swap partition first, then I use simple dd command to clone it with bootloader and everything and for last I do create new swap partition. Somebody can say I can do same with simple script which can resize root and left swap like originally was inside root because we do not want to use swap at all on slow these cards and it is here for emergency. Answer is you have right. Swapfile on microsd card is for emergency cases only because it has low I/O bandwitch and I personally do prefer using swap partition if it is necessary on singleboard computers with sata port attached ssd's (even somebody can protest we do swaps on spindle drives because it do not lower it's lifetime). https://www.linux.com/news/all-about-linux-swap-space

@p117 Welcome on board. USB-dongles are usually auto-mounted on a newly created mount point in /media. This is how you force it to be mounted at a predefined mount point. 1. Create a new mount point for your USB-dongle sudo mkdir /mnt/mydrive 2. Plug in your USB-drive and check the partition name ( e.g. /dev/sda1 ) Your drive is most likely formatted as vfat. sudo blkid /dev/mmcblk0p1: UUID="56a9eae3-fd35-47d4-a01c-00251c2d6a8d" TYPE="ext4" PARTUUID="00003286-01" /dev/mmcblk0: PTUUID="00003286" PTTYPE="dos" /dev/sda1: UUID="4732-9959" TYPE="vfat" 3. Use the unique identifier (UUID) of the filesystem on your USB-drive and add an entry to your /etc/fstab sudo nano /etc/fstab #----sample fstab-entry to mount specific USB-drive # the unique identifier UUID can be queried with # blkid # UUID="4732-9959" /mnt/mydrive vfat defaults,noatime 0 2 4. When you reboot, the USB-drive will be automatically mounted at /mnt/mydrive. Adjust permissions if needed. 5. Enjoy

The latter is nearly useless (since some holes here and there do not lead to the massive amount of airflow that would be needed to enhance the efficiency of an applied heatsink -- stuff you can simply try out using RPi-Monitor) and you only need a heatsink if you care about 'top performance' since throttling does the job to protect the SoC. Most recent ARM SoCs are specified to work in temperature ranges where you would burn your fingers when touching them. But that's nothing to worry about as long as you're using a kernel that implements throttling (applies to sun8i legacy kernel but not mainline now -- patches already exist but none of us managed to apply them together with the other needed H3 patches so far)

Hi guys, Yesterday I updated my Orange PI PC with build 5.10. I want to build custom wifi driver using dkms. Dkms requires kernel scripts but scripts build fails with following error: root@orangepipc:/usr/src/linux-headers-3.4.112-sun8i# make scripts scripts/kconfig/conf --silentoldconfig Kconfig fs/Kconfig:287: can't open file "fs/fs_compat.kconfig" /usr/src/linux-headers-3.4.112-sun8i/scripts/kconfig/Makefile:33: recipe for target 'silentoldconfig' failed make[2]: *** [silentoldconfig] Error 1 /usr/src/linux-headers-3.4.112-sun8i/Makefile:493: recipe for target 'silentoldconfig' failed make[1]: *** [silentoldconfig] Error 2 make: *** No rule to make target 'include/config/auto.conf', needed by 'scripts'. Stop. File "fs/fs_compat.kconfig" doesn't exist.

Still not working for me. Below is the current error Armbian 5.11 building for a cubox-i Though I get the same for an OrangePiPlus [ o.k. ] Creating board support package [ cubox-i ] [ o.k. ] Fingerprinting [ Armbian 5.11 Cubox-i Debian wheezy default Linux ] [ o.k. ] Building package [ linux-wheezy-root-cubox-i ] [ o.k. ] Starting build process for [ cubox-i wheezy ] [ o.k. ] Extracting wheezy-ng-armhf.dbd...9ec.tgz [ 0 days old ] wheezy-ng-armhf.dbd...9ec.tgz: 51.2MB [11.9MB/s] [=========================================================================================>] 100% mount: mount point /usr/src/amp/output/cache/sdcard/proc does not exist mount: mount point /usr/src/amp/output/cache/sdcard/sys does not exist mount: mount point /usr/src/amp/output/cache/sdcard/dev does not exist mount: mount point /usr/src/amp/output/cache/sdcard/dev does not exist mount: mount point /usr/src/amp/output/cache/sdcard/dev/pts does not exist [ o.k. ] Applying distribution specific tweaks for [ wheezy ] /usr/src/amp/lib/distributions.sh: line 23: /usr/src/amp/output/cache/sdcard/etc/apt/apt.conf.d/71-no-recommends: No such file or directory cp: cannot create regular file ‘/usr/src/amp/output/cache/sdcard/etc/apt/apt.conf.d/50unattended-upgrades’: No such file or directory cp: cannot create regular file ‘/usr/src/amp/output/cache/sdcard/etc/apt/apt.conf.d/02periodic’: No such file or directory sed: can't read /usr/src/amp/output/cache/sdcard/etc/apt/apt.conf.d/50unattended-upgrades: No such file or directory sed: can't read /usr/src/amp/output/cache/sdcard/etc/apt/apt.conf.d/50unattended-upgrades: No such file or directory chroot: failed to run command ‘/bin/bash’: No such file or directory chroot: failed to run command ‘/bin/bash’: No such file or directory rm: cannot remove ‘/usr/src/amp/output/cache/sdcard/tmp/ramlog_2.0.0_all.deb’: Not a directory sed: can't read /usr/src/amp/output/cache/sdcard/etc/default/ramlog: No such file or directory sed: can't read /usr/src/amp/output/cache/sdcard/etc/init.d/rsyslog: No such file or directory sed: can't read /usr/src/amp/output/cache/sdcard/etc/init.d/rsyslog: No such file or directory sed: can't read /usr/src/amp/output/cache/sdcard/etc/default/console-setup: No such file or directory chroot: failed to run command ‘/bin/bash’: No such file or directory chroot: failed to run command ‘/bin/bash’: No such file or directory touch: cannot touch ‘/usr/src/amp/output/cache/sdcard/root/.not_logged_in_yet’: No such file or directory chroot: failed to run command ‘/bin/bash’: No such file or directory chroot: failed to run command ‘/bin/bash’: No such file or directory cp: failed to access ‘/usr/src/amp/output/cache/sdcard/tmp/’: Not a directory chroot: failed to run command ‘/bin/bash’: No such file or directory [ o.k. ] Installing packages [ linux-image-cubox ] /usr/src/amp/lib/boards.sh: line 186: /usr/src/amp/output/cache/sdcard/etc/default/cpufrequtils: No such file or directory /usr/src/amp/lib/boards.sh: line 187: /usr/src/amp/output/cache/sdcard/etc/default/cpufrequtils: No such file or directory /usr/src/amp/lib/boards.sh: line 188: /usr/src/amp/output/cache/sdcard/etc/default/cpufrequtils: No such file or directory /usr/src/amp/lib/boards.sh: line 189: /usr/src/amp/output/cache/sdcard/etc/default/cpufrequtils: No such file or directory rm: cannot remove ‘/usr/src/amp/output/cache/sdcard/etc/resolv.conf’: No such file or directory cp: target ‘/usr/src/amp/output/cache/sdcard/etc/network/’ is not a directory ln: failed to create symbolic link ‘/usr/src/amp/output/cache/sdcard/etc/network/interfaces’: No such file or directory mount: mount point /usr/src/amp/output/cache/sdcard/tmp is not a directory chroot: failed to run command ‘/bin/bash’: No such file or directory [ o.k. ] Installing u-boot [ linux-u-boot-cubox-i ] chroot: failed to run command ‘/bin/bash’: No such file or directory [ o.k. ] Installing headers [ linux-headers-cubox ] chroot: failed to run command ‘/bin/bash’: No such file or directory cp: cannot create regular file ‘/usr/src/amp/output/cache/sdcard/boot/boot.bmp’: No such file or directory checkdir: cannot create extraction directory: /usr/src/amp/output/cache/sdcard/lib/firmware No such file or directory sed: can't read /usr/src/amp/output/cache/sdcard/etc/lirc/hardware.conf: No such file or directory sed: can't read /usr/src/amp/output/cache/sdcard/etc/lirc/hardware.conf: No such file or directory cp: cannot create regular file ‘/usr/src/amp/output/cache/sdcard/etc/lirc/lircd.conf’: No such file or directory cp: cannot create regular file ‘/usr/src/amp/output/cache/sdcard/usr/local/bin/brcm_patchram_plus’: No such file or directory chroot: failed to run command ‘/bin/bash’: No such file or directory chroot: failed to run command ‘/bin/bash’: No such file or directory [ o.k. ] Install board support package [ cubox-i ] chroot: failed to run command ‘/bin/bash’: No such file or directory chroot: failed to run command ‘/bin/bash’: No such file or directory [ o.k. ] Creating boot scripts [ cubox-i ] cp: cannot create regular file ‘/usr/src/amp/output/cache/sdcard/boot/boot.cmd’: No such file or directory umount: /usr/src/amp/output/cache/sdcard/tmp: not mounted [ o.k. ] Installing extra applications and drivers [ o.k. ] Building deb [ hostapd ] [ o.k. ] Downloading sources [ hostapd ] /usr/src/amp/lib/extras/hostapd.sh: line 103: cd: /usr/src/amp/output/cache/sdcard/tmp/hostap: Not a directory cat: /usr/src/amp/output/cache/sdcard/tmp/hostap/src/common/version.h: Not a directory [ o.k. ] Compiling [ v ] cp: failed to access ‘/usr/src/amp/output/cache/sdcard/tmp/hostap/src/drivers/’: Not a directory cp: failed to access ‘/usr/src/amp/output/cache/sdcard/tmp/hostap/hostapd/.config’: Not a directory cat: /usr/src/amp/output/cache/sdcard/tmp/hostap/hostapd/main.c: Not a directory [ error ] Not built [ hostapd ] [ error ] ERROR in function unmount_on_exit [ debootstrap-ng.sh:516 ] [ error ] debootstrap-ng was interrupted [ o.k. ] Process terminated make: *** [all] Error 255

According to this page https://forums.linuxmint.com/viewtopic.php?t=162677(linuxmint being based on Ubuntu), the package util-linux in which there is blkid could be outdated and not supporting PARTUUID. My desktop is Linuxmint 17.3 based on Ubuntu 14.04 ant util-linux version is "2.20.1-5.1 ubuntu20.7". Command blkid on my desktop doesn't show "PARTUUID", only "UUID". On my Cubieboard2 with Debian 8 Jessie, This package is in version "2.25.2-6". And PARTUUID is shown with blkid. Maybe this is the reason ? PARTUUID on your Ubuntu version is not supported and you can't mount it from it ? I am not an expert, though.

dmesg (booting from mmc) dmesg (booting from mmc after attaching usb) lsmod (booting from mmc no usb connected) lsmod (booting from mmc after attaching usb) blkid (strangely, blkid does not povide PARTUUID on cubietruck. Attaching the same USB disck on my laptop, blkid provides PATRUUID as specified in the boot.cmd below) mount from my laptop Boot.cmd (rootfs @USB) fstab (I tried with UUID and PARTUUID)

Hi guy, Once time i had datacorruption on my scard so i investigated a way to recovery entire sdcard or make an fsck at startup. Problem,,,root partition is mountedand in use! So you can edit fstab to put root fs in readonly mode, make an fsck and a dd like you want. Inconvenient : very long process and server is down. Avantage : you can reload original armbian OS into a new sdcard and after recovery your dd image directly on the OPPC (because I have some trouble with big 8GB dd transfert with sdcard usb adapter) from an external flash or hdd. Here is my note to doing that (in french sorry) : faire un dd de la sd: 1. editer fstab en ro remplacer defaults par ro,suid,dev,exec,auto,nouser,async # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sda7 during installation UUID=33b870b8-a81e-4203-a4fd-7affa9f412fb / ext4 errors=remount-ro 0 1 # /boot was on /dev/sda5 during installation UUID=c3cc32c0-b4bd-49f6-b23c-35fed37adea5 /boot ext2 defaults 0 2 # /home was on /dev/sda8 during installation UUID=c2d386a1-c2f9-4d2f-957a-65a5d9b4c4d7 /home ext4 defaults 0 2 2. mettre pass à 1 pour un fsck au demarage 3. faire le dd vers un cle usb 4. restaurer fstab comme avant en remontant en rw : mount -o remount,rw /dev/sda2 puis edition fstab 5. reinstaller lightdm 6. rebooter

I'm with you phleum. Wheezy is better than Jessie, in my humble opinion, for several reasons. Is there a problem or incompatibility putting Stretch (testing) with Armbian repository?. I want to update multiple systems. Jessie missing some packages I need, do exist in Wheezy and Stretch, and I would not mix versions

Not any more, I imported a dedicated fex file for M1+ a while ago since some differences do exist. But since it's a SinoVoip product and they really don't get the idea why documenting hardware features correctly should matter I would assume that there are still some errors present. I tried to correct a few of the known ones (all user contributed from forums discussions since SinoVoip doesn't care as usual) and here we are: https://github.com/igorpecovnik/lib/commit/b25abe478b1512b4221076886b4c465cf12510ec#diff-2245023265ae4cf87d02c8b6ba991139 You might notice that I enabled I2S in the fex file with the 2nd commit and now it looks like this: https://github.com/igorpecovnik/lib/blob/master/config/fex/bananapim1plus.fex#L948-L958 But since I've not the hardware [1] I can not say whether the pin mappings are correct or not. Please report back after using this fex file (translate it with fex2bin please). [1] I tried to order an M1+ a few months ago from their European distributor but the typical 'SinoVoip experience' applies to these guys too. They told me Banana Pi Pro would've been discontinued (not true, I didn't ask for the Pro but M1+ instead and they don't even sell this board since it's LeMaker's), then they tried to sell me the M2 instead (no thanks) and so on.

This is a question only you can answer. You always mix up everything with everything, exchange client and server role, do not use real 'logon credentials' but always rely on your LOCAL username when trying to access the Windows machine and so on. Start with a more methodological approach and you will succeed. At least try to use a dedicated username when using smbclient (-U $USER-THAT-DOES-EXIST-ON-WINDOWS)

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

Hi to All, I try to use a button connected between GND and GPIO PB18 (ID=50) which is pulled up on Lime2-eMMC. The idea is to force booting from eMMC when the button is pushed at boot. I have also connected 2x LEDS to GPIOs PC23 (ID=87) and PC23 (ID=88). I have modified boor.cmd as follows: if gpio input 50; then gpio set 87; setenv devtype mmc; setenv devnum 0; setenv distro_bootpart 1; else gpio set 88; fi part uuid ${devtype} ${devnum}:${distro_bootpart} uuid echo Booting ${devtype} ${devnum}:${distro_bootpart} UUID=${uuid} if load ${devtype} ${devnum}:${distro_bootpart} 0x00000000 /boot/.verbose; then setenv verbosity 7; else setenv verbosity 1; fi setenv bootargs console=${console} root=PARTUUID=${uuid} rootfstype=ext4 rw rootwait panic=10 loglevel=${verbosity} ${extended_bootargs} if load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} /boot/zImage; then if load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} /boot/dtb/${fdtfile}; then if load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}; else bootz ${kernel_addr_r} - ${fdt_addr_r}; fi; fi; fi if load ${devtype} ${devnum}:${distro_bootpart} 0x48000000 /boot/uImage; then if load ${devtype} ${devnum}:${distro_bootpart} 0x43000000 /boot/script.bin; then setenv bootm_boot_mode sec; bootm 0x48000000; fi; fi # Recompile with: # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr and everything works fine except first if statement. I expect when the button is not pushed (gpio input value is 1) to be run 'then' case but it is really running 'else' case: ... Scanning scsi 0:1... Found U-Boot script /boot/boot.scr 1314 bytes read in 39 ms (32.2 KiB/s) ## Executing script at 43100000 gpio: pin 50 (gpio 50) value is 1 gpio: pin 88 (gpio 88) value is 1 Booting scsi 0:1 UUID=aa89ba3d-01 ... and when the button is pushed (gpio input value is 0) backward but it is really running 'then' case: ... Scanning scsi 0:1... Found U-Boot script /boot/boot.scr 1314 bytes read in 39 ms (32.2 KiB/s) ## Executing script at 43100000 gpio: pin 50 (gpio 50) value is 0 gpio: pin 87 (gpio 87) value is 1 Booting mmc 0:1 UUID=e1604232-01 ... Can somebody explain this behavior? Best regards Chris

Ok, that works, it was the PARTUUID's fault ! /dev/mmcblk0: PTUUID="0006426d" PTTYPE="dos" /dev/mmcblk0p1: UUID="01bed786-74eb-4262-9f51-1c604e65c951" TYPE="ext4" PARTUUID="0006426d-01" /dev/sda1: UUID="83ce9744-1e54-4191-af69-d7a7fcfeedbe" TYPE="ext4" PARTUUID="000c8dd7-01" /dev/sda2: UUID="20753884-8113-4c2e-a9fe-0e2322f84c16" TYPE="ext4" PARTUUID="000c8dd7-02" I had to use "000c8dd7-01" in my boot env line. My fstab was correct. Thank you

@berturion This doesn't look like PARTUUID unless you are using GPT on your USB drive. Partition UUID will work without initrd, while filesystem UUID won't. Look at this output of "blkid" for example: # blkid /dev/sda1: LABEL="share" UUID="25616f82-0842-4af4-aea8-8ee54cf2df9d" TYPE="xfs" PARTUUID="0004cde8-01" /dev/sdb1: LABEL="Red" UUID="4a6e870b-f6f7-4b68-9864-55da3b328a75" TYPE="xfs" PARTLABEL="Red" PARTUUID="dccadf90-01e7-4624-99f9-9858ce11ea8f" /dev/sda is using MBR, /dev/sdb is using GPT. If you are using PARTUUID correctly, please try to get a boot log on serial console and post it here.