Search the Community

Showing results for tags 'tutorial'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Announcements & first aid
    • Announcements
    • Board doesn't start
  • Community forums
    • Common issues / peer to peer technical support
    • Reviews, Tutorials, Hardware hacks
    • Help wanted
    • Feature Requests
    • TV boxes
    • General chit chat
  • Bug tracker - supported boards and images only
    • Allwinner A20
    • Allwinner H2 & H3
    • Allwinner A64, H5, H6 and H616
    • Armada A388, A3700
    • Amlogic S905(x), S922X
    • NXP (Freescale)
    • Rockchip 3288 & 3328
    • Rockchip 3399
    • Other supported boards
  • Development
    • Development
  • TV Boxes's General Chat
  • TV Boxes's Reviews/Tutorials
  • TV Boxes's FAQ
  • TV Boxes's TV Boxes running Armbian
  • TV Boxes's Rockchip CPU Boxes
  • TV Boxes's Amlogic CPU Boxes
  • TV Boxes's Allwinner CPU Boxes
  • Android fanboys's Forums
  • Gaming on ARM's Reviews
  • Gaming on ARM's Issues
  • Kobol Forum's Helios4
  • Kobol Forum's Helios64

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP


Skype


Github


Location


Interests

  1. Full root filesystem encryption on an Armbian system (new, fully rewritten, replaces my earlier tutorial on this topic) MMGen (https://github.com/mmgen) This tutorial provides detailed, step-by-step instructions for setting up full root filesystem encryption on an Armbian system. The disk can be unlocked remotely via SSH or the serial console, permitting unattended bootup. An automated script that performs the same steps, saving you much time and effort, can be found at https://github.com/mmgen/mmgen-geek-tools Note that unlike my earlier tutorial all steps are performed within a running Armbian system. The tutorial is known to work with the following board/image combinations: Orange Pi PC2 Debian Buster mainline / Ubuntu Bionic and Focal legacy RockPi 4 Debian Buster mainline / Ubuntu Bionic and Focal legacy RockPro 64 Ubuntu Focal mainline Odroid HC4 Debian Buster mainline / Ubuntu Focal mainline You may have success with other boards/images too. If so, please post the details below (or open an issue in the mmgen-geek-tools Github repository), and I’ll add your board to the list. Requirements: A SoC with a running, upgradeable and Internet-connected Armbian system A blank Micro-SD card and USB card reader, or, alternatively, a blank eMMC installed on the board The ability to edit text files and do simple administrative tasks on the Linux command line Step 1 - Preliminaries All steps in this tutorial are performed as root user on a running Armbian system (the “host”). The encrypted system (the “target”) will be created on a blank micro-SD card. If your board has an eMMC not currently in use, the system can be created on it instead. Architecture of host and target (e.g. 64-bit or 32-bit ARM) must be the same. For best results, the host and target hardware should also be identical or similar. Building on a host with more memory than the target, for example, may lead to disk unlocking failure on the target. If you’re building the target system for the currently running board and with the currently running image, which is the recommended approach, the two preceding points will be a non-issue. Packages will be installed using APT, so the host machine must be Internet-connected and its clock correctly set. Step 2 - Upgrade your system and install the cryptsetup-bin package # apt update && apt upgrade # apt install cryptsetup-bin Step 3 - Get and unpack the latest Armbian image for your board Create your build directory: # mkdir armbenc-build && cd armbenc-build Download the Armbian image of your choice for your board, place it in this directory and unpack: # xz -dv *.img.xz Step 4 - Create mount directories and set up the loop mount Create the mount directories: # mkdir -p mnt boot root Determine your first free loop device: # losetup -f Associate the image file with the loop device name displayed by the previous command. This will be '/dev/loop0' in most cases, but if your output was different, substitute that for '/dev/loop0' in the following steps. # losetup -P /dev/loop0 *.img Examine the disk image using fdisk on the loop device: # fdisk -l /dev/loop0 The output should look something like this: Device Boot Start End Sectors Size Id Type /dev/loop0p1 32768 3489791 3457024 1.7G 83 Linux Make a note of the start sector (32768 in this case). You’ll need this value in the steps below. Now mount the loop device: # mount /dev/loop0p1 mnt Step 5 - Copy the boot loader to the SD card Insert the blank micro-SD card and card reader into a USB port. Determine the SD card’s device name using 'dmesg' or 'lsblk'. We’ll assume it to be '/dev/sda', since that’s the most likely case. If your device name is different, substitute it for '/dev/sda' in the the following steps. For an eMMC, the device name will probably be '/dev/mmcblk1'. WARNING: if '/dev/sda' refers to some other storage device, running the following commands unchanged will destroy data on that device, so always remember to substitute the correct device name!!! The best way to eliminate this danger is to disconnect all unused storage devices on the board before proceeding further. Copy the image’s boot loader to the SD card, using the Start sector value from Step 4 as the argument for 'count': # dd if=$(echo *.img) of=/dev/sda bs=512 count=32768 Step 6 - Partition the SD card # fdisk /dev/sda At the fdisk prompt, create a new DOS disk label with the 'o' command. Use the 'n' command to create a primary partition of size +200M beginning at the same Start sector as the disk image. Type 'p' to view the partition table, which should now look something like this: Device Boot Start End Sectors Size Id Type /dev/sda1 32768 442367 409600 200M 83 Linux Use 'n' again to create another primary partition beginning one sector after the first partition’s end sector and filling the remainder of the card. Type 'p' once more to view the partition table: Device Boot Start End Sectors Size Id Type /dev/sda1 32768 442367 409600 200M 83 Linux /dev/sda2 442368 30636031 30193664 14.4G 83 Linux Ensure that the first partition’s Start sector matches that of the disk image (32768 in this example) and that the second partition’s Start sector is one greater than the End sector of the first (442368 and 442367, respectively, in this example). If you’ve made a mistake, use 'd' to delete a partition and start again. Once everything looks correct, type 'w' to write the partition table to disk. Step 7 - Copy the system to the SD card The following commands will create a filesystem on the SD card’s boot partition and copy the boot partition data from the image file to it. Don’t forget to substitute the correct device name if necessary. If you’re building the system on an eMMC, the boot partition device is likely to be '/dev/mmcblk1p1' instead of '/dev/sda1'. # mkfs.ext4 /dev/sda1 # or '/dev/mmcblk1p1', for an eMMC target # e2label /dev/sda1 CRYPTO_BOOT # mount /dev/sda1 boot # cp -av mnt/boot/* boot # (cd boot; ln -s . boot) Create the encrypted root partition. When prompted for a passphrase, it’s advisable to choose an easy one like 'abc' for now. The passphrase can be changed later with the 'cryptsetup luksChangeKey' command (type 'man cryptsetup' for details) once your encrypted system is up and running. # cryptsetup luksFormat /dev/sda2 # or '/dev/mmcblk1p2', for an eMMC target Activate the encrypted root partition and create a filesystem on it: # cryptsetup luksOpen /dev/sda2 rootfs # enter your passphrase from above # mkfs.ext4 /dev/mapper/rootfs Mount the encrypted root partition and copy the system to it: # mount /dev/mapper/rootfs root # (cd mnt && rsync -a --info=progress2 --exclude=boot * ../root) # sync # be patient, this could take a while # mkdir root/boot # touch root/root/.no_rootfs_resize Unmount the boot partition and image and free the loop device: # umount mnt boot # losetup -d /dev/loop0 Step 8 - Prepare the target system chroot # BOOT_PART=($(lsblk -l -o NAME,LABEL | grep CRYPTO_BOOT)) # ROOT_PART=${BOOT_PART%1}2 # ROOT_UUID="$(lsblk --nodeps --noheadings --output=UUID /dev/$ROOT_PART)" # BOOT_UUID="$(lsblk --noheadings --output=UUID /dev/$BOOT_PART)" # cd root # mount /dev/$BOOT_PART boot # mount -o rbind /dev dev # mount -t proc proc proc # mount -t sysfs sys sys Copy '/etc/resolv.conf' and '/etc/hosts' so you’ll have a working Internet connection within the chroot: # cat /etc/resolv.conf > etc/resolv.conf # cat /etc/hosts > etc/hosts If you’re using non-default APT repositories, you may need to copy their configuration files as well so that 'apt update' and 'apt install' will use them inside the chroot. Note that you can only do this if the host and target systems have the same distro/version. If that’s not the case, you’ll have to edit the target files by hand. # cat /etc/apt/sources.list > etc/apt/sources.list # cat /etc/apt/sources.list.d/armbian.list > etc/apt/sources.list.d/armbian.list If you’re using an apt proxy, then copy its configuration file too: # cp /etc/apt/apt.conf.d/*proxy etc/apt/apt.conf.d/ Step 9 - Edit or create required configuration files in the target system Perform the editing steps below using a text editor of your choice: Edit 'boot/armbianEnv.txt' so that the 'rootdev', 'console' and 'bootlogo' lines read as follows. If you’ll be unlocking the disk via the serial console, then use 'console=serial' instead of 'console=display'. Note that enabling the serial console will make it impossible to unlock the disk from the keyboard and monitor, though unlocking via SSH will still work: rootdev=/dev/mapper/rootfs console=display bootlogo=false Edit 'etc/initramfs-tools/initramfs.conf'. If your board will have a statically configured IP, add the following line to the end of the file, substituting the correct IP in place of 192.168.0.88: IP=192.168.0.88:::255.255.255.0::eth0:off If the board will be configured via DHCP, then edit the DEVICE line as follows: DEVICE=eth0 If host and target systems are both Debian buster, you may wish add some key modules to the initramfs to avoid a blank display at bootup time. The easiest way to do this is to add all currently loaded modules as follows: # lsmod | cut -d ' ' -f1 | tail -n+2 > etc/initramfs-tools/modules Retrieve the SSH public key from the remote unlocking host and copy it to the target: # mkdir -p etc/dropbear-initramfs # rsync yourusername@remote_machine:.ssh/id_*.pub etc/dropbear-initramfs/authorized_keys If you want to unlock the disk from more than one host, then edit the authorized_keys file by hand, adding the required additional keys. Create 'etc/crypttab': # echo "rootfs UUID=$ROOT_UUID none initramfs,luks" > etc/crypttab Create 'etc/fstab': # echo '/dev/mapper/rootfs / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1' > etc/fstab # echo "UUID=$BOOT_UUID /boot ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 2" >> etc/fstab # echo 'tmpfs /tmp tmpfs defaults,nosuid 0 0' >> etc/fstab Create the dropbear configuration file: # echo 'DROPBEAR_OPTIONS="-p 2222"' > etc/dropbear-initramfs/config # echo 'DROPBEAR=y' >> etc/dropbear-initramfs/config If the target is Ubuntu bionic, then a deprecated environment variable must be set as follows: # echo 'export CRYPTSETUP=y' > etc/initramfs-tools/conf.d/cryptsetup Set up automatic disk unlock prompt. Performing this optional step will cause the disk password prompt to appear automatically when you log in remotely via SSH to unlock the disk. Using your text editor, create the file 'etc/initramfs-tools/hooks/cryptroot-unlock.sh' with the following contents: #!/bin/sh if [ "$1" = 'prereqs' ]; then echo 'dropbear-initramfs'; exit 0; fi . /usr/share/initramfs-tools/hook-functions source='/tmp/cryptroot-unlock-profile' root_home=$(echo $DESTDIR/root-*) root_home=${root_home#$DESTDIR} echo 'if [ "$SSH_CLIENT" ]; then /usr/bin/cryptroot-unlock; fi' > $source copy_file ssh_login_profile $source $root_home/.profile exit 0 Save the file and execute the command: chmod 755 'etc/initramfs-tools/hooks/cryptroot-unlock.sh' Step 10 - Chroot into the target system, install packages and configure Now chroot into the encrypted system. All remaining steps will be performed inside the chroot: # chroot . Install the cryptsetup package and the dropbear SSH server: # apt update # echo 'force-confdef' > /root/.dpkg.cfg # apt --yes install cryptsetup-initramfs dropbear-initramfs # for a buster or focal image # apt --yes install cryptsetup dropbear-initramfs # for a bionic image # rm /root/.dpkg.cfg Make sure everything was included in the initramfs (all three commands should produce output): # lsinitramfs /boot/initrd.img* | grep 'usr.*cryptsetup' # lsinitramfs /boot/initrd.img* | grep dropbear # lsinitramfs /boot/initrd.img* | grep authorized_keys Your work is finished! Exit the chroot and shut down the board: # exit # halt -p Insert your freshly written SD card into the board’s main SD slot (or, if the target is an eMMC, just remove the SD card from that slot) and reboot. Unlock the disk by executing the following command on your remote unlocking machine, substituting the correct IP address if necessary: $ ssh -p 2222 root@192.168.0.88 If you performed step 9.10 above, the disk password prompt should appear automatically after login. If not, you must enter the command 'cryptroot-unlock'. You may also unlock the disk from the target board’s console if you wish. Note, however, that certain disk images (RockPi 4 buster mainline, for example) might give you a blank display at startup, so you’ll have to enter your disk password “blindly”. This bug will hopefully be fixed in the future. If all went well, your root-filesystem encrypted Armbian system is now up and running!
  2. I have written a shell script that can make your Armbian installation run on a ZFS root. It has not been tested enough for my liking. Use at your own risk. Before running this script, please make a full backup of all your mission-critical files. URL: https://www.dropbox.com/s/ya3expllg1bqgfg/fructify.20211011.sh.gz To install the script, please run these commands:- # sudo wget https://www.dropbox.com/s/ya3expllg1bqgfg/fructify.20211011.sh.gz -O /usr/local/bin/fructify.sh.gz # sudo gunzip /usr/local/bin/fructify.sh.gz # sudo chmod +x /usr/local/bin/fructify.sh Oh, and install ZFS on your own OS installation. To use the script, either download an existing Armbian image or use your own system as the basis for the new installation. Next, please make sure (i) there is a blank micro-SD card in an adapter, (ii) the adapter is plugged into a USB port, and (iii) you know which /dev entry refers to that adapter’s USB port. It will probably be /dev/sda; please do not assume so. In the below commands, replace sdX with sda (or whatever). Method 1: Download and use an existing Armbian image # wget https://mirrors.netix.net/armbian/dl/nanopineo3/archive/Armbian_21.08.1_Nanopineo3_focal_current_5.10.60.img.xz -O /root/npneo3_focal.img.xz # xz -d /root/npneo3_focal.img.xz # fructify.sh /root/npneo3_focal.img.xz zfs /root/out.img # dd status=progress bs=1024k if=/root/out.img of=/dev/sdX Method 2: Use your existing filesystem as the basis # fructify.sh / zfs /dev/sdX In either case, please take care not to write the image to the wrong device. This script can also work with btrfs, ext4, or xfs. The script assumes that you have only one partition on your boot drive. That drive is usually /dev/mmcblk0; the boot/root partition is expected to be /dev/mmcblk0p1. It may be that the script also works if the boot drive is /dev/mmcblk1 and the boot/root partition is /dev/mmcblk1p1; I do not know. In any case, the script shrinks partition #1 (for boot) and allocates approximately 4GB to a newly created partition #2 (for root). If you create a ready-to-install Armbian image and boot it on a micro-SD card, the OS will expand partition #2 to fill the remainder of the micro-SD card. If you create a ZFS-ified (or whatever) copy of your existing installation, the SD card’s second partition will already have been expanded by the script itself. All feedback is welcome. I am new at this. Thank you.
  3. Hi, There's been a few guides around on how to get RDP working with Armbian so you can login from your Windows or other PC. Some solutions mentioned in various threads here were: Install tightvncserver instead + x2go bloat (i.e. use VNC) Only login as root - didn't seem to make any difference for me Change some permissions of a log file in your home directory. Well, this is what I did on my Orange PI PC running Buster desktop with Kernel 5.4, as of April 2020. sudo apt install xrdp xorgxrdp sudo systemctl enable xrdp sudo reboot ... and that was it. The missing piece of the puzzel appeared to be the install of xorgxrdp, this isn't installed automatically by 'xrdp' package, and it's useless without it. Update June 2020: Also works with RetroOrangePi 4.3 super quickly (given this is based on Armbian Bionic 18.04). Can RDP in and use Armbian Desktop whilst Kodi plays a 4k movie on the TV from the same device... Awesome!
  4. It seems that the actual install routine of Pihole doenst detect buster with kernel 5.8 correctly. At "my" normal install command "curl -sSL https://install.pi-hole.net | bash" I did get [✗] Unsupported OS detected: Armbian 20.08.0-trunk Buster https://docs.pi-hole.net/main/prerequesites/#supported-operating-systems e.g: If you are seeing this message on a fresh install, you can run: 'curl -sSL https://install.pi-hole.net | PIHOLE_SKIP_OS_CHECK=true sudo -E bash' If you are seeing this message after having run pihole -up: 'PIHOLE_SKIP_OS_CHECK=true sudo -E pihole -r' (In this case, your previous run of pihole -up will have already updated the local repository) but after giving (as written above) the install command with the option "to not check the OS" curl -sSL https://install.pi-hole.net | PIHOLE_SKIP_OS_CHECK=true sudo -E bash the installation went fine
  5. Normally you could install (if you use a 64Bit arm-system/OS) the 64Bit version of stockfish with apt install stockfish stockfish is a uci-chess-engine where some Chessboard-Display-Apps can conenct to (later I would show how to use this with TCP) Then you will get (at this time) the Version 8 64Bit = 8 64 = 11/2016 But the actual stockfish-engine is at Version 10 = 12/2018 ( see http://blog.stockfishchess.org/ ) So I did clone the git-master at https://github.com/official-stockfish/Stockfish as .zip After unzipping and cd to ./Stockfish-master/src you could do -make clean -make help BUT there is for arm only a ARCH=armv7 (32Bit) option When using the ARCH=general-64 option make build ARCH=general64 COMP=gcc COMPCXX=g++ then the start of the compile did fail because g++ says that he didnt knows the -m64 commandline-option I searched the Web and found there no solution So I did take a look into the Makefile and first I didnt found anything about -m64, but then I discoverd in the gcc-options the follwing part which I then deleted: else CXXFLAGS += -m$(bits) LDFLAGS += -m$(bits) after that I did create a aarch64-ARCH-section under the armv7-ARCH-section: ifeq ($(ARCH),aarch64) arch = any prefetch = yes bits = 64 endif arch = any is copied from the "general-64" section, prefetch is copied from the "armv7"-section and maybe the "bits = 64" is obsolete? Now we can compile - there are two options: dpkg -l|grep 'g++' ii g++ 4:6.3.0-4 arm64 GNU C++ compiler ii g++-6 6.3.0-18+deb9u1 arm64 GNU C++ compiler make build ARCH=aarch64 COMP=gcc COMPCXX=g++ make build ARCH=aarch64 COMP=gcc COMPCXX=g++-6 When the compile has completed you will have the executeable stockfish in your ./Stockfish-master/src directory. see stockfish_10_64 as attached binary at the end of this thread-message When started you will see: Stockfish 140319 64 by T. Romstad, M. Costalba, J. Kiiski, G. Linscott Enter uci and you will see the stockfish-info: id name Stockfish 140319 64 id author T. Romstad, M. Costalba, J. Kiiski, G. Linscott option name Debug Log File type string default option name Contempt type spin default 24 min -100 max 100 option name Analysis Contempt type combo default Both var Off var White var Black var Both option name Threads type spin default 1 min 1 max 512 option name Hash type spin default 16 min 1 max 131072 option name Clear Hash type button option name Ponder type check default false option name MultiPV type spin default 1 min 1 max 500 option name Skill Level type spin default 20 min 0 max 20 option name Move Overhead type spin default 30 min 0 max 5000 option name Minimum Thinking Time type spin default 20 min 0 max 5000 option name Slow Mover type spin default 84 min 10 max 1000 option name nodestime type spin default 0 min 0 max 10000 option name UCI_Chess960 type check default false option name UCI_AnalyseMode type check default false option name SyzygyPath type string default <empty> option name SyzygyProbeDepth type spin default 1 min 1 max 100 option name Syzygy50MoveRule type check default true option name SyzygyProbeLimit type spin default 7 min 0 max 7 uciok You could leave the stockfish chess-engine with quit I will add (these days) a tutorial for setting up stockfish as TCP-Service (via inetd) and then we could connect via Windows/Android/Linux ChessBoard-Display-Apps to play with the stockfish engine on your 64Bit ARM-System Preview-Information-Links for setting up , connecting and playing with the engine: https://somoit.net/linux/linux-create-custom-inetd-service https://jerrygreenblog.wordpress.com/2016/08/26/linux-stockfish-chess-engine-as-remote-service/ http://aartbik.blogspot.com/2012/03/connecting-chess-for-android-to-remote.html stockfish_10_64
  6. Orange Pi Zero NTP Stratum 1 PPS GPS Server with Armbian OS. Link to the Tutorial - http://schwartzel.eu3.org/ntp-stratum1.html This tutorial uses a 3.3V capable GPS module with PPS output - TOPGNSS GN-701 (u-blox 7) but other similar modules should work. This tutorial is for the Orange Pi Zero, but will probably work for other boards. I couldn't easily do a comprehensive hardware and software tutorial on this forum, so I've published it on my web server and linked from here and attached a PDF. Link to the Tutorial - http://schwartzel.eu3.org/ntp-stratum1.html Tutorial PDF ntp-stratum1.pdf If you spot any typo's or errors please let me know.
  7. Over a year (or two?) I used a PS1-line in my ~/-bashrc with many cryptic ANSI-Escape-codes which were hard to read and edit export PS1='\[\033[1;36m\]\u\[\033[1;37m\]@\[\033[1;33m\]\h\[\033[1;37m\](\[\033[1;32m\]$THEIP\[\033[1;37m\])\[\033[1;31m\]:\[\033[1;36m\]\w\[\033[1;31m\]\$\[\033[0m\] ' Today I did installed Linux Lite 4.6 on a PC (a former Chromebox) and did see the nice Powerline prompt and did try to use that on a nanoPi Neo2. I installed the packages fonts-powerline & powerline and copied the powerline-script /usr/share/powerline/bindings/bash/powerline.sh from the pc to the NanoPi Neo2. It did work after I used UTF8 translation in pUTTY, but it wasnt very perfomant So I decided to cleanup my PS1 line for better reading, I had to define some variables and then I did put these in my PS1 export line in ~/.bashrc: export THEIP="$(/sbin/ifconfig | grep "inet " | grep -v 127.0.0. | awk '{print $2}')" BRed='\[\033[31;1m\]' BGreen='\[\033[32;1m\]' BYellow='\[\033[33;1m\]' BCyan='\[\033[36;1m\]' BWhite='\[\033[37;1m\]' Reset='\[\033[0m\]' UserPromptPS1='\$' export PS1="${BCyan}\u${BWhite}@${BYellow}\h${BWhite}(${BGreen}${THEIP}${BWhite})${BRed}:${BCyan}\w${BRed}${UserPromptPS1}${Reset} " # \u = User # @ = @ # \h = Host # \w = working directory # \$ = # for root (uid=0) or $ for user That worked well and did give me the same result as my old but bad readable PS1-line Now its - for me - much more easy to edit As Information some more useable color-definition (B before the color is for Bright and colors starting with On are for the Background): Black='\[\033[30m\]' Red='\[\033[31m\]' Green='\[\033[32m\]' Yellow='\[\033[33m\]' Blue='\[\033[34m\]' Magenta='\[\033[35m\]' Cyan='\[\033[36m\]' White='\[\033[37m\]' BBlack='\[\033[30;1m\]' BRed='\[\033[31;1m\]' BGreen='\[\033[32;1m\]' BYellow='\[\033[33;1m\]' BBlue='\[\033[34;1m\]' BMagenta='\[\033[35;1m\]' BCyan='\[\033[36;1m\]' BWhite='\[\033[37;1m\]' OnBlack='\[\033[40m\]' OnRed='\[\033[41m\]' OnGreen='\[\033[42m\]' OnYellow='\[\033[43m\]' OnBlue='\[\033[44m\]' OnMagenta='\[\033[45m\]' OnCyan='\[\033[46m\]' OnWhite='\[\033[47m\]' OnBBlack='\[\033[40;1m\]' OnBRed='\[\033[41;1m\]' OnBGreen='\[\033[42;1m\]' OnBYellow='\[\033[43;1m\]' OnBBlue='\[\033[44;1m\]' OnBMagenta='\[\033[45;1m\]' OnBCyan='\[\033[46;1m\]' OnBWhite='\[\033[47;1m\]' Reset='\[\033[0m\]'
  8. Canon provides source code for cups driver, but with some proprietary binary libs. This libs available only for x86. No way for direct compiling cnijfilter for ARM (and other architectures). But we have qemu! We can transparently run x86 executables on any other host architectures. Easy steps to run cnijfilter on ARM (or any other arch): - Build https://github.com/endlessm/cnijfilter-common for x86 - Copy all needed x86 libs using recursive ldd. And copy it to /usr/lib/bjlib/ - Patch all executables: set interpreter to /usr/lib/bjlib/x86/ld-linux.so.2 and rpath to /usr/lib/bjlib/ - Install these patched packages to ARM system - Install qemu-user and qemu-user-binfmt (or qemu-arm-static) You do not need to do this manually. I have implemented an automated build system: https://github.com/Azq2/cnijfilter-arm-build All you need is any x86 machine to do the build. How to use 1. On any x86 machine: # Install dependencies sudo apt install debootstrap git util-linux # Get build system git clone https://github.com/Azq2/cnijfilter-arm-build # Start building cd cnijfilter-arm-build sudo ./build.sh build # Get .deb packages ls -lah ./result/full ls -lah ./result/light After build we have two variants of packages: full and light Item Full Light PPD files + + CUPS filters + + CUPS backends + - lgmon + - canon-maintenance + - cngpij + - cngpijmnt + - cnijlgmon2 + - cnijnetprn + - cnijnpr + - docs + - In most cases, a light package is completely sufficient: - We don't need canon usb backend, because cups have builtin USB support - We don't need canon network backend, because cups have builtin BJNP support (package cups-backend-bjnp) - Other canon maintenance utils are useless (in my opinion) 2. Copy .deb from result/light or result/full to your ARM machine. 3. On your ARM machine: # Install dependencies sudo apt install qemu-user qemu-user-binfmt # or sudo apt install qemu-user-static # Install common for all printers package sudo dpkg -i cnijfilter-common.deb # Install printer-specific package # Choose right package for your printer! e400series only for reference! sudo dpkg -i cnijfilter-e400series.deb 4. Done. You can now configure CUPS. Security with apparmor (optional) CUPS filters don't need any specific permissions. Create file /etc/apparmor.d/cnijfilter-filters with contents: #include <tunables/global> /usr/bin/bjfilter* { #include <abstractions/base> @{PROC}/sys/vm/mmap_min_addr r, } /usr/bin/cif[a-z]*[0-9d]* { #include <abstractions/base> @{PROC}/sys/vm/mmap_min_addr r, } /usr/lib/cups/filter/{cmdtocanonij,pstocanonbj,pstocanonij} { #include <abstractions/base> @{PROC}/sys/vm/mmap_min_addr r, } Then restart apparmor: sudo systemctl reload apparmor sudo aa-enforce cnijfilter-filters Note: this minimal file full coverage all executables in light package. For full package you need write additional rules by yourself.
  9. Hereby a tutorial to connect an MCP2515 based CAN bus interface to an OrangePi 3 running successfull with Buster minimal nightly with 5.3 kernel. It uses the attached user overlay only and doesn’t need any other overlay. Connections CAN module OPi3 26 pin header Raspberry CAN interface 40 pin header Vcc 3.3 CON12-P01 1 Gnd CON12-P06 6 MOSI CON12-P19 19 MISO CON12-P21 21 CLK CON12-P23 23 CS CON12-P24 24 INT CON12-P26 22 Optional 5V for Transceiver on cheap Chinese modules CON12-P02 Not used when equiped with a 3.3V transceiver Add the attached overlay with the command: sudo armbian-add-overlay spi-h6-mcp2515.dts The file /boot/armbianEnv.txt now contains a line: user_overlays=spi-h6-mcp2515 Reboot the OrangePi 3 Check if the MCP2515 is recognized: pi@orangepi3:~$ dmesg | grep mcp If properly connected it should return a line containing: mcp251x spi1.0 can0: MCP2515 successfully initialized. As stated a can0 interface should be generated check it with: pi@orangepi3:~$ sudo ifconfig -a Bring up the network: sudo ip link set can0 up type can bitrate 250000 Check if the interrupt is hooked: cat /proc/interrupts should return a line like this 46: 1 0 0 0 sunxi_pio_edge 8 Edge mcp251x Check for traffic on the CAN bus with candump from can-utils (sudo apt-get install can-utils) candump can0 spi-h6-mcp2515.dts
  10. Hi all. In this video I show how to install Open Media Vault on your SBC with Armbian Buster. I've used the Odroid HC4, this is the same for any board you'd like to use. Here my video. Greetings. NicoD
  11. EDIT: 04.01.2020 - Fixed patches to work with latest armbian sources. (references have changed) Hi everybody, Here is a tutorial to enable the Lemaker 7" Touchscreen on BananaPi Pro with Debian Buster and Mainline-Kernel 5.XX.XX. Kernel: Mainline 5.4.6 / Buster Board: BananaPi Pro WebLinks: • https://forum.armbian.com/topic/1905-enabling-lcd-in-u-boot-kernel-472/ • https://forum.armbian.com/topic/1849-touch-driver-banana-pi/ • http://www.atakansarioglu.com/getting-started-bananapi-linux/ • http://forum.lemaker.org/thread-15482-1-1.html • http://linux-sunxi.org/LCD To make the 7"LCD and the Touchscreen working with BananaPi Pro we need to patch some files and change the kernel config to build the driver for the touchscreen. To do this we need a working setup of the Armbian build tool chain (https://docs.armbian.com/Developer-Guide_Build-Preparation/) /home/<USER>/build/cache/sources/u-boot/v201X.XX/configs/Bananapro_defconfig /home/<USER>/build/cache/sources/u-boot/v201X.XX/arch/arm/dts/sun7i-a20-bananapro.dts /home/<USER>/build/cache/sources/linux-mainline/linux-4.XX.y/arch/arm/boot/dts/sun7i-a20-bananapro.dts 1. U-Boot ( u-boot version that supports the LCD - must be compiled) Start the build process with ./compile.sh CREATE_PATCHES=yes When asked for: [ warn ] Applying existing u-boot patch [ /home/[USER]/build/output/patch/u-boot-sunxi-current.patch ] [ warn ] Make your changes in this directory: [ /home/[USER]/build/cache/sources/u-boot/v201X.XX ] [ warn ] Press <Enter> after you are done [ waiting ] a) edit /home/<USER>/build/cache/sources/u-boot/v201X.XX/configs/Bananapro_defconfig add the following: #7" LVDS LCD CONFIG_VIDEO_LCD_MODE="x:1024,y:600,depth:24,pclk_khz:55000,le:100,ri:170,up:10,lo:15,hs:50,vs:10,sync:3,vmode:0" CONFIG_VIDEO_LCD_PANEL_LVDS=y CONFIG_VIDEO_LCD_POWER="PH12" CONFIG_VIDEO_LCD_BL_EN="PH8" CONFIG_VIDEO_LCD_BL_PWM="PB2" b) edit /home/<user>/build/cache/sources/u-boot/v201X.XX/arch/arm/dts/sun7i-a20-bananapro.dts add after: &i2c2 { ... }; the following: &i2c3 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&i2c3_pins>; edt: edt-ft5x06@38 { compatible = "edt,edt-ft5x06", "edt,edt-ft5206"; reg = <0x38>; pinctrl-names = "default"; pinctrl-0 = <&edt_ft5x06_pins_a &edt_ft5x06_pins_b>; interrupt-parent = <&pio>; interrupts = <7 9 IRQ_TYPE_EDGE_FALLING>; touchscreen-size-x = <1024>; touchscreen-size-y = <600>; }; }; Add these two new sections to the end of the file: &pio { edt_ft5x06_pins_a: ft5@0 { pins = "PH9"; function = "irq"; drive-strength = <20>; bias-pull-up; }; edt_ft5x06_pins_b: ft5@1 { pins = "PH7"; function = "gpio_out"; drive-strength = <20>; bias-pull-up; output-high; }; }; &pwm { pinctrl-names = "default"; pinctrl-0 = <&pwm0_pin>, <&pwm1_pin>; status = "okay"; }; Then save and press <Enter> to continue. 2. Kernel patches - DTB (Device Tree Blob) file that fits to your Kernel and supports pwm When asked for: [ warn ] Applying existing kernel patch [ /home/<USER>/build/output/patch/kernel-sunxi-current.patch ] [ warn ] Make your changes in this directory: [ /home/<USER>/build/cache/sources/linux-mainline/orange-pi-5.XX ] [ warn ] Press <Enter> after you are done [ waiting ] c) edit /home/<USER>/build/cache/sources/linux-mainline/orange-pi-5.XX/arch/arm/boot/dts/sun7i-a20-bananapro.dts add the same lines like section b) Then save and press <Enter> to continue. 3. Compile Touchdriver menuconfig > Device Drivers > Input Device Support > Touchscreens > EDT FocalTech FT5x06 I2C Touchscreen support Exit and save the Kernel configuration. This is the outcome. You probably have a newer version than 19.11.4: Now you can flash the image to a SD-Card or you have to install the new DEBs. dpkg -i linux-u-boot-current-bananapipro_19.11.4_armhf.deb dpkg -i linux-dtb-current-sunxi_19.11.4_armhf.deb dpkg -i linux-image-current-sunxi_19.11.4_armhf.deb reboot The result: The LCD and the touchscreen are working. Attention! There is still the problem with the shutdown. When the patches were made for the LCD, the board did not shut down completely during a shutdown (LCD still had voltage and the red LED on the board did not go out). Workaround: We need to disable the LCD before the shutdown is finished. Therfore we have to create a script in the folder /lib/systemd/system-shutdown e.g. (as root) touch /lib/systemd/system-shutdown/lcd_off.sh chmod +x /lib/systemd/system-shutdown/lcd_off.sh nano /lib/systemd/system-shutdown/lcd_off.sh add these lines: #!/bin/bash # LCD Power PH12 H=8 (8-1)*32+12 = 236 # Backlight enable PH8 H=8 (8-1)*32+8 = 232 # Backlight PWM PB2 B=2 (2-1)*32+2 = 34 if [ ! -d "/sys/class/gpio/gpio34" ] then sudo sh -c 'echo "34" > /sys/class/gpio/export' sudo sh -c 'echo "out" > /sys/class/gpio/gpio34/direction' sudo sh -c 'echo "1" > /sys/class/gpio/gpio34/value' fi if [ ! -d "/sys/class/gpio/gpio232" ] then sudo sh -c 'echo "232" > /sys/class/gpio/export' sudo sh -c 'echo "out" > /sys/class/gpio/gpio232/direction' sudo sh -c 'echo "1" > /sys/class/gpio/gpio232/value' fi if [ ! -d "/sys/class/gpio/gpio236" ] then sudo sh -c 'echo "236" > /sys/class/gpio/export' sudo sh -c 'echo "out" > /sys/class/gpio/gpio236/direction' sudo sh -c 'echo "1" > /sys/class/gpio/gpio236/value' fi # LCD on/off sudo sh -c 'echo "0" > /sys/class/gpio/gpio34/value' sudo sh -c 'echo "0" > /sys/class/gpio/gpio232/value' sudo sh -c 'echo "0" > /sys/class/gpio/gpio236/value' The script will be executed right before the board powers off. Measured power consumption: PowerON (booting / lcd still off) = 0.4A - 0.5A LCD turns on (still booting) = 0.85A - 1.05A Boot process ended (LCD on) = 0.75A Board on, LCD off = 0.35A - 0.45A ( -> LCD needs around 0.4A power ) shutdown -h now = 0.00A 4. Control the Power of the Backlight: The backlight PWM is on PIN CON2 PB2. Following the instructions on http://linux-sunxi.org/GPIO#Accessing_the_GPIO_pins_through_sysfs_with_mainline_kernel http://forum.lemaker.org/thread-10852-1-1.html we have to export GPIO-PIN 34. (position of letter in alphabet - 1) * 32 + pin number position of letter in alphabet: B = 2 pin number: 2 ( 2 - 1 ) * 32 + 2 = 34 echo 34 > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio34/direction Power on the Backlight: echo "1" > /sys/class/gpio/gpio34/value Power off the Backlight: echo "0" > /sys/class/gpio/gpio34/value Now we could use a switch connected to a GPIO-IN to control the backlight. Steffen
  12. For enabling - to use stockfish/armfish-chess-engine - as a TCP service we need to configure (add the lines at the end of the file) /etc/inetd.conf #:OTHER: Other services stockfish08 stream tcp nowait guido /usr/games/stockfish stockfish10 stream tcp nowait guido /usr/games/stockfish_10_64 armfish stream tcp nowait guido /usr/games/armfish_aarch64 and add the TCP-Port - we want to use - to the /etc/services (for optical reasons after pop3s port 995/tcp) pop3s 995/tcp # POP-3 over SSL # # stockfish08 1024/tcp # stockfish 8 chess engine stockfish10 1025/tcp # stockfish 10 chess engine armfish 1026/tcp # armfish chess engine at the end we have to restart inetd (or reboot) systemctl restart inetd Additional (important?) informations: - guido is a local user on my system - you need to change the name for the /etc/inetd.conf to a local user of your system - /usr/games/stockfish is the stockfish-binary installes by apt install stockfish - the stockfish-binary we compiled for stockfish v10 64Bit in another thread from ./Stockfish-master/src/stockfish (directory of the cloned github-repository) to /usr/games/stockfish_10_64 - /usr/games/armfish_aarch64 is the (on a 64Bit PC-Linux compiled with fasmg) assembler-version of stockfish which could run twice as fast see https://github.com/lantonov/asmFish precompiled aarch64-binary as attachment (think about the chmod 755 armfish_aarch64 after the transfer ) Binary-Overview in /usr/games/ root@t95k-pro(192.168.6.62):/usr/games# ls -l insgesamt 644 -rwxr-xr-x 1 root root 128050 Mär 14 22:08 armfish_aarch64 -rwxr-xr-x 1 root root 216216 Nov 12 2016 stockfish -rwxr-xr-x 1 root root 308896 Mär 14 13:57 stockfish_10_64 armfish_aarch64
  13. Dear Armbian community, although I'm using Armbian a lot, I never had to submit anything to this forum (fortunately, because it works so well :-)), On my PC I've experienced lags on heavy IO operations. After a short dig into available information, I found a useful Cloudflare article on Kernel queues together with dm-crypt. A good & short summary on possible actions for users can be found here: https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Disable_workqueue_for_increased_solid_state_drive_(SSD)_performance Enabling the no-read-workqueue & no-write-workqueue options helped a lot! As I'm using a RockPi4 with the NVMe SSD with encryption, I thought this should apply to my SBC as well. Unfortunately, Armbian/Debian Buster uses cryptsetup v2.1.0 which does NOT support these options. According to the changelog, this option was introduced in v2.3.4: https://gitlab.com/cryptsetup/cryptsetup/-/blob/master/docs/v2.3.4-ReleaseNotes As Armbian uses a kernel > 5.9, the kernel infrastructure should be available. Fortunately, crypsetup v2.3.4 exists in the buster-backports repo: https://packages.debian.org/buster-backports/cryptsetup Solution: # sudo apt install cryptsetup/buster-backports
  14. Hi all. I've done a lot of tests with different desktop environments on Armbian. I wanted an as light as possible desktop environment so I'd have enough ram left to do video rendering with the NanoPi M4(2GB) I had to try a lot of things to get things working fine. So I wanted to save others that hassle. Setting up Display Manager First we need a Display Manager. NODM is installed by default. I tried lightdm but couldn't get it to work. So I went for LXDM. With NODM installed I had problems, so I also removed NODM. To be sure lxdm is configured right, I also manually configure it. sudo apt install lxdm sudo apt remove nodm sudo dpkg-reconfigure lxdm Install LXDE Desktop Next step is to install the desktop environment you want. There is a problem with some Desktop Environments and LXDM what makes you can't login to some DE's out of the box. That we will resolve later. Easiest is to install lxdm first to be able to configure the others well. And reboot. sudo apt install lxde sudo reboot Once booted you should be greeted by the Login screen. Here you can choose your different Desktop Environment. Choose LXDE and login. If you'd try xfce4, then you'd see it doesn't work. To fix this we need to change the file /usr/share/xsessions/xfce.desktop. Use your favorite text editor. I use geany. sudo geany /usr/share/xsessions/xfce.desktop Somewhere at the top of the file you'll see "Name=Xfce Session". Replace that space with a hyphen to "Name=Xfce-Session" and save the file. Now you can also login to the default XFCE4 Desktop. With other desktops this can be the same. Go the the same directory and open the file with the desktop name that doesn't work. Again replace the space with a hyphen Installing different Desktop Environments. For the Mate desktop I also needed to install the applets, else I got errors at login because of these missing applets sudo apt install mate-desktop-environment mate-applets For KDE-Plasma sudo apt install kde-full For Gnome. Modify the file sudo geany /usr/share/xsessions/gnome... sudo apt install gnome-session sudo update-alternatives --config gdm3.css I also tried LXQT. But this one didn't work. You can try others too. Remove Desktop Environment To remove a desktop environment you don't want anymore you do the remove instead of install. sudo apt remove kde-full sudo apt remove mate-desktop-environment . . . Please let me know if there's mistakes made, or if you've got advice. Source for changing the name to make them work @IgorS : Greetings, NicoD
  15. Access to a console can be mandatory when you SBC doesn't work as expected (e.g Network or HDMI output doesn't work). When SSH/Display access isn't possible access to console via UART is the best way to get a clue where your SBC hangs. This short tutorial should give you an introduction how this works. For some boards, armbian implements an USB gadget mode (a 'fake' serial console over microUSB) describen below. As a reminder an USB-UART bridge is always prefered over USB gadget mode whenever possible (UART get's initialized before the gadget driver and also before HDMI, means even if you don't get a proper output from HDMI or gadget mode console, it is possible that UART will give you the needed information). Prerequisites: We need an Terminal program to access the console. If you use Linux on your host system I prefer picocom (something like minicom will also do the job) which can be installed: on debian a like systems: sudo apt-get install picocom from arch community repo: https://www.archlinux.org/packages/community/x86_64/picocom/ on fedora systems: yum install picocom on Mac OS X: brew install picocom on Widows we use PuTTY: https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html UART USB Adapter: There are various USB-UART bridges e.g FT232 (and fakes of them, cause FDTI is expensive ), CH340/1,PL2303 or CP2102 Normally it doesn't matter which one you use. I prefer the (probably fake) FDTI on the right side, but the CH341 does also a good job: The only thing which is needed is that the signal-level matches with your SBCs needs (this is mostly 3.3V expect some Odroids e.g HC1 which has only 1.8V!). Most of these USB-UART bridges have jumpers for 5V and 3.3V, make sure that you use the 3.3V. You've to figure out which pins on your SBC are debug UART (they've mostly a own 3 pin header, sometimes it's on the large pin header e.g. Tinkerboard) and then connect: GND --> GND RX --> TX TX --> RX You've to check dmesg (linux) or run devmgmt.msc (windows) to know which device you use. Linux: [256597.311207] usb 3-2: Product: USB2.0-Serial [256597.402283] usbcore: registered new interface driver ch341 [256597.402341] usbserial: USB Serial support registered for ch341-uart [256597.402392] ch341 3-2:1.0: ch341-uart converter detected [256597.404012] usb 3-2: ch341-uart converter now attached to ttyUSB0 --> Device will be /dev/ttyUSB0 Windows: for windows 10 (https://www.google.ch/search?client=opera&amp;q=find+arduino+port+windows+10&amp;sourceid=opera&amp;ie=UTF-8&amp;oe=UTF-8) Something like the picture in USB Gadget Mode part of the tutorial should show up) Armbians default settings are (expect some RK devices): For Picocom: picocom -b 115200 -r -l /dev/ttyUSB0 and for some RK devices: picocom -b 1500000 -r -l /dev/ttyUSB0 For PuTTY: You've to set configuration in 'Serial'. COM11 is just an example and needs to be checked first, Speed (baud) needs to be changed when you deal with the few RK boards which need 1500000. OS X: TBD should be similar to Linux whereas the naming differs a bit. See: https://forum.odroid.com/viewtopic.php?f=53&amp;t=841 as an example with minicom. Normally you connect the USB-UART bridge to your host computer (and the SBC) and start picocom/putty before you power the board to ensure you get the full bootlog and not only parts of it. USB Gadget Mode Several board (see list) for which official armbian images exist (or csc images can be built) have no HDMI display. On those boards there's USB gadget mode driver activated so that you can have console access to them via USB connection. The following short tutorial describes how you can access to console from Linux (don't have a windows machine here at the moment, I may check it later): install picocom connect your board via USB to your host computer (it should be one which is able to power an SBC via its USB port) check dmesg for the device showing up: [184372.603816] usb 3-2: Product: Gadget Serial v2.4 [184372.603818] usb 3-2: Manufacturer: Linux 4.14.65-sunxi with musb-hdrc [184372.660041] cdc_acm 3-2:2.0: ttyACM0: USB ACM device [184372.660402] usbcore: registered new interface driver cdc_acm [184372.660403] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters connect to it via picocom (in this case 'picocom /dev/ttyACM0'): chwe@chwe-acer:~$ picocom /dev/ttyACM0 picocom v2.2 port is : /dev/ttyACM0 flowcontrol : none baudrate is : 9600 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, Type [C-a] [C-h] to see available commands Terminal ready Debian GNU/Linux 9 orangepizero ttyGS0 orangepizero login: root Password: You are required to change your password immediately (root enforced) Changing password for root. (current) UNIX password: I assume if you use the same settings in something like putty on windows and you check which 'serial' device shows up in *where windows shows connected devices - I forgot it* you should be able to access it from windows (someone motivated may confirm this). For Windows: run devmgmt.msc and search for the serial device (in this case COM3) and connect to it via PuTTY (thanks to @hjc): for windows 10 (https://www.google.ch/search?client=opera&amp;q=find+arduino+port+windows+10&amp;sourceid=opera&amp;ie=UTF-8&amp;oe=UTF-8): (even the tutorial is for arduinos, it should be similar for every 'COM device') Currently boards with USB gadget mode: bananapim2plus bananapim2zero nanopifire3 nanopim3 nanopineo2 nanopineocore2 nanopineoplus2 orangepizeroplus nanopiair nanopiduo nanopineo olimex-som204-a20 orangepilite orangepi-r1 orangepizero orangepizeroplus2-h3 orangepizeroplus2-h5 tritium-h3 The silly approach For those, who want to save 1$ for an USB-UART bridge, you can spend 10$ for an OrangePi Zero and use its spare UARTs to log into an other SBC... SSH --> opi, ttl --> Tinkerboard For those loving text more than videos: SSH to your SBC sudo armbian-config --> system --> hardware to activate an spare UART (in this case it was UART2, will give you ttyS2) reboot picocom -b 115200 -r -l /dev/ttyS2 See: https://asciinema.org/a/B87EOGhc0gx9oikMAGEG94lXR
  16. Panfrost instructions Armbian !!!! I made a script that does all this, check a few posts later for the script !!!!! This tutorial explains how to build an Armbian image with panfrost. And what else you need to make it work. These are early drivers. Many things don't work yet. Only OpenGL 2.1 works now. You need to build an image with kernel 5.2 or later. For this you need an x86 pc with Ubuntu 18.04 or a virtual Ubuntu 18.04 x86 image. First install git, then clone the build folder from Armbian, and enter the build directory. apt-get -y -qq install git git clone --depth 1 https://github.com/armbian/build cd build Now run the script with EXPERT=yes so you can choose to build a dev image. sudo ./compile EXPERT=yes Choose "Full OS image for flashing" Then "Show a kernel configuration menu before compilation" Choose your board. If it's not in the regular list, look in "Show SCS/WIP/EOS/TVB". Choose Development version kernel configuration -> device drivers -> graphic drivers -> panfrost Let it run until it's finished. The image will be in the /build/output/images Burn it to an SD-card/eMMC/... Now we need to install all the needed software sudo apt install flex bison python3-mako libwayland-egl-backend-dev libxcb-dri3-dev libxcb-dri2-0-dev libxcb-glx0-dev libx11-xcb-dev libxcb-present-dev libxcb-sync-dev libxxf86vm-dev libxshmfence-dev libxrandr-dev libwayland-dev libxdamage-dev libxext-dev libxfixes-dev x11proto-dri2-dev x11proto-dri3-dev x11proto-present-dev x11proto-gl-dev x11proto-xf86vidmode-dev libexpat1-dev libudev-dev gettext glmark2 glmark2-es2 mesa-utils xutils-dev libpthread-stubs0-dev ninja-build bc python-pip flex bison cmake git valgrind llvm llvm-8-dev python3-pip pkg-config zlib1g-dev wayland-protocols Download and install meson wget http://ftp.de.debian.org/debian/pool/main/m/meson/meson_0.55.3-1_all.deb sudo dpkg -i meson_0.55.3-1_all.deb Download and install mesa DRM git clone git://anongit.freedesktop.org/mesa/drm cd drm meson build --prefix=/usr ninja -C build sudo -E ninja -C build install cd .. Download and install mesa graphics git clone git://anongit.freedesktop.org/mesa/mesa cd mesa meson -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=panfrost,kmsro -Dlibunwind=false -Dprefix=/usr build/ ninja -C build/ sudo ninja -C build/ install REBOOT Optionally, update sdl (recommended) git clone https://github.com/SDL-mirror/SDL.git cd SDL mkdir build cd build cmake ../ make -j6 sudo make install REBOOT Only thing that works ok with it is supertuxkart, to install it. sudo apt install supertuxkart Panfrost - Linux games working from repo SuperTuxKart - Works well ExtremeTuxRacer - lots of glitches AssaultCube - lots of glitches Instructions by Salvador Liébana & NicoD
  17. Hi all. I've just finished a new video where I show how to build Armbian images on your ARM SBC. Here is the video. All have a jolly good Christmas or other holiday or normal day.
  18. Is OPI ONE a toy or a toy ? Yes and yes and a fun one too ! The following experiment shows the OPI ONE in use as a Virtual Desktop Server AND Virtual Desktop Client. Setup as Virtual Desktop Server ( remotely access headless OPI ONE desktop ) OPI ONE : install xrdp and tightvncserver <clients> : install and configure remote desktop ( rdesktop on linux, aRDP on android - not yet tested on OS-X or WIN ) Setup as Virtual Desktop Client ( OPI ONE securely accesses a remote linux desktop ) OPI ONE : install x2goclient <server> : install x2goserver on linux server ( physical or virtual ) of choice This document explains the experiment ( you have to click/enlarge pictures in your browser .. sorry ) And here is a screenshot of the actual session : Red : Linux server desktop connecting to OPI ONE via rdesktop / xrdp Orange : OPI ONE desktop connecting to UK virtual server via x2goclient/x2goserver Purple : virtual server (UK) desktop running libreoffice White : actual document being edited ( incl. drawings ! ) in window ( Headline : Italian guy in Switzerland abuses OPI ONE to edit nerd stuff in the UK ) Remote desktop access from smartphone ( cheap Wiko Lenny 2 ) for touch-fumbling nano-fingers Remote desktop access from tablet ( Galaxy Note 8.0 ) using pen There are numerous use cases covered with the simple techniques employed.Thanks to the Armbian team and the forum buddies for their excellent job in making OPI ONE usable. Have fun !
  19. Focal / root on eMMC / ZFS on hdd / LXD / Docker I received my Helios64 yesterday, installed the system, and decided to write down my steps before I forget them. Maybe someone will be interested. :-) Preparation: Assembly your box as described here. Download Armbian Focal image from here and flash it to SD card. You may use Ether. Insert the SD card to your Helios64 and boot. After 15-20s the box should be accessible via ssh. (Of course you have to find out it's IP address somehow. For example check your router logs or use this.) First login: ssh root@IP Password: 1234 After prompt - change password and create your daily user. You should never login as root again. Just use sudo in the future. :-) Note: The auto-generated user is member of "disk" group. I do not like it. You may remove it so: "gpasswd -d user disk". Now move your system to eMMC: apt update apt upgrade armbian-config # Go to: System -> Install -> Install to/update boot loader -> Install/Update the bootloader on SD/eMMC -> Boot from eMMC / system on eMMC You can choose root filesystem. I have chosen ext4. Possibly f2fs might be a better idea, but I have not tested it. When finished - power off, eject the sd card, power on. Your system should now boot from eMMC. If you want to change network configuration (for example set static IP) use this: "sudo nmtui". You should also change the hostname: sudo armbian-config # Go to: Personal -> Hostname ZFS on hard disk: sudo armbian-config # Go to Software and install headers. sudo apt install zfs-dkms zfsutils-linux # Optional: sudo apt install zfs-auto-snapshot # reboot Prepare necessary partitions - for example using fdisk or gdisk. Create your zfs pool. More or less this way: sudo zpool create -o ashift=12 -m /mypool -mypool mirror /dev/disk/by-partuuid/abc123 /dev/disk/by-partuuid/xyz789 Reboot and make sure the pool is imported automatically. (For example by typing "zpool status".) You should now have working system with root on eMMC and ZFS pool on HDD. Docker with ZFS: Prepare the filesystem: sudo zfs create -o mountpoint=/var/lib/docker mypool/docker-root sudo zfs create -o mountpoint=/var/lib/docker/volumes mypool/docker-volumes sudo chmod 700 /var/lib/docker/volumes # Option: If you use zfs-auto-snapshot, you might want to consider this: sudo zfs set com.sun:auto-snapshot=false mypool/docker-root sudo zfs set com.sun:auto-snapshot=true mypool/docker-volumes Create /etc/docker/daemon.json with the following content: { "storage-driver": "zfs" } Add /etc/apt/sources.list.d/docker.list with the following content: deb [arch=arm64] https://download.docker.com/linux/ubuntu focal stable # deb-src [arch=arm64] https://download.docker.com/linux/ubuntu focal stable Install Docker: sudo apt install apt-transport-https ca-certificates curl gnupg-agent software-properties-common curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add - sudo apt update sudo apt install docker-ce docker-ce-cli containerd.io #You might want this: sudo usermod -aG docker your-user Voila! Your Docker should be ready! Test it: "docker run hello-world". Option: Install Portainer: sudo zfs create rpool/docker-volumes/portainer_data # You might omit the above line if you do not want to have separate dataset for the docker volume (bad idea). docker volume create portainer_data docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce Go to http://yourip:9000 and configure. LXD with ZFS: sudo zfs create -o mountpoint=none mypool/lxd-pool sudo apt install lxd sudo lxc init # Configure ZFS this way: Do you want to configure a new storage pool (yes/no) [default=yes]? yes Name of the new storage pool [default=default]: Name of the storage backend to use (dir, btrfs, ceph, lvm, zfs) [default=zfs]: zfs Create a new ZFS pool (yes/no) [default=yes]? no Name of the existing ZFS pool or dataset: mypool/lxd-pool [...] #You might want this: sudo usermod -aG lxd your-user # Option: If you use zfs-auto-snapshot, you might want to consider this: sudo zfs set com.sun:auto-snapshot=false mypool/lxd-pool sudo zfs set com.sun:auto-snapshot=true mypool/lxd-pool/containers sudo zfs set com.sun:auto-snapshot=true mypool/lxd-pool/custom sudo zfs set com.sun:auto-snapshot=true mypool/lxd-pool/virtual-machines That's it. Lxd should work now on ZFS. :-)
  20. I did that on a NanoPi Neo with the FriendlyARM PCM5102A Hat ( https://www.friendlyarm.com/index.php?route=product/product&amp;product_id=169 ) using kernel 4.14.87-sunxi and armbian 5.67 (or later would be only 5.65?) (before that I did use legacy kernel 3.4.x with the PCM510A) and the armbian-BuildSystem plus (THANKS to) informations in threads from @dony71 , @Christos, @Valery Rezvyakov and the the Reference-Threads you could find above ---------------------------------------------------------------------------------------------------------------------------------- BACKUP DTB (on NanoPi Neo) ---------------------------------------------------------------------------------------------------------------------------------- cp /boot/dtb/sun8i-h3-nanopi-neo.dtb /boot/dtb/sun8i-h3-nanopi-neo.dtb_org ---------------------------------------------------------------------------------------------------------------------------------- CONVERT dtb to dts (on NanoPi Neo) ---------------------------------------------------------------------------------------------------------------------------------- dtc -I dtb -O dts /boot/dtb/sun8i-h3-nanopi-neo.dtb -o /boot/dtb/sun8i-h3-nanopi-neo.dts ---------------------------------------------------------------------------------------------------------------------------------- EDIT /boot/dtb/sun8i-h3-nanopi-neo.dts ---------------------------------------------------------------------------------------------------------------------------------- nano /boot/dtb/sun8i-h3-nanopi-neo.dts - change: status from "disabled" to "okay" ---------------------------------------------------------------------------------------------------------------------------------- FROM i2s@1c22000 { #sound-dai-cells = <0x0>; compatible = "allwinner,sun8i-h3-i2s"; reg = <0x1c22000 0x400>; interrupts = <0x0 0xd 0x4>; clocks = <0x3 0x38 0x3 0x54>; clock-names = "apb", "mod"; dmas = <0x13 0x3 0x13 0x3>; resets = <0x3 0x2b>; dma-names = "rx", "tx"; status = "disabled"; phandle = <0x4e>; }; TO i2s@1c22000 { #sound-dai-cells = <0x0>; compatible = "allwinner,sun8i-h3-i2s"; reg = <0x1c22000 0x400>; interrupts = <0x0 0xd 0x4>; clocks = <0x3 0x38 0x3 0x54>; clock-names = "apb", "mod"; dmas = <0x13 0x3 0x13 0x3>; resets = <0x3 0x2b>; dma-names = "rx", "tx"; status = "okay"; phandle = <0x4e>; }; ---------------------------------------------------------------------------------------------------------------------------------- CONVERT (BACK) dts to dtb (on NanoPi Neo) ---------------------------------------------------------------------------------------------------------------------------------- dtc -I dts -O dtb /boot/dtb/sun8i-h3-nanopi-neo.dts -o /boot/dtb/sun8i-h3-nanopi-neo.dtb_I2S_okay ---------------------------------------------------------------------------------------------------------------------------------- COPY new dtb over dtb (on NanoPi Neo) ---------------------------------------------------------------------------------------------------------------------------------- cp /boot/dtb/sun8i-h3-nanopi-neo.dtb_I2S_okay /boot/dtb/sun8i-h3-nanopi-neo.dtb ---------------------------------------------------------------------------------------------------------------------------------- COPY sun8i-h3-I2S-out.dts to home (working directory on NanoPi Neo) ---------------------------------------------------------------------------------------------------------------------------------- copy sun8i-h3-I2S-out.dts --> /home/guido/ ---------------------------------------------------------------------------------------------------------------------------------- armbian-add-overlay (on NanoPi Neo) does only work if you got the kernel-headers installed for your actual kernel-version (at this time the lastest kernel-header are (via armbian-config -> Software -> Install Headers) Linux kernel headers for 4.14.84-sunxi on armhf - so NOT for kernel 4.19.y) ---------------------------------------------------------------------------------------------------------------------------------- root@npi-neo(192.168.6.24):/home/guido# armbian-add-overlay ./sun8i-h3-I2S-out.dts Compiling the overlay Copying the compiled overlay file to /boot/overlay-user/ Reboot is required to apply the changes ---------------------------------------------------------------------------------------------------------------------------------- dtbo is created (on NanoPi Neo) ---------------------------------------------------------------------------------------------------------------------------------- root@npi-neo(192.168.6.24):/home/guido# ls -l /boot/overlay-user/ insgesamt 4 -rw-r--r-- 1 root root 1323 Dez 7 19:34 sun8i-h3-I2S-out.dtbo ---------------------------------------------------------------------------------------------------------------------------------- user-overlay is created in /boot/armbianEnv.txt (on NanoPi Neo) ---------------------------------------------------------------------------------------------------------------------------------- verbosity=1 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost1 usbhost2 rootdev=UUID=33ca90d6-130b-4d5f-a8f4-95b3b97ef5c0 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u user_overlays=sun8i-h3-I2S-out ---------------------------------------------------------------------------------------------------------------------------------- now REBOOT (on NanoPi Neo) ---------------------------------------------------------------------------------------------------------------------------------- root@npi-neo(192.168.6.24):~# lsmod|grep i2s sun4i_i2s 16384 0 snd_soc_core 118784 2 sun4i_i2s,sun8i_codec_analog snd_pcm 69632 3 sun4i_i2s,snd_pcm_dmaengine,snd_soc_core ---------------------------------------------------------------------------------------------------------------------------------- EDIT config-default.conf (on armbian-BuildSystem) ---------------------------------------------------------------------------------------------------------------------------------- cd /home/guido/build nano ./config-default.conf replace content /home/guido/build/config-default.conf with attached config-default.conf_nanopineo ./compile -> With this conf, script compilation will stop to overwrite kernel source to build patch -> At that time, overwrite original Kconfig with the one you modified above (at "Make changes to U-Boot" press ENTER to proceed) wait for "Make your changes to /home/guido/build/cache/sources/linux-mainline/linux-4.14.y then press ENTER" BUT DONT PRESS ENTER YET ---------------------------------------------------------------------------------------------------------------------------------- EDIT/SAVE Kconfig in a 2nd shell-Window (on armbian-BuildSystem) ---------------------------------------------------------------------------------------------------------------------------------- nano /home/guido/build/cache/sources/linux-mainline/linux-4.14.y/sound/soc/codecs/Kconfig the part FROM config SND_SOC_PCM5102A tristate TO config SND_SOC_PCM5102A tristate "Texas Instruments PCM5102A CODEC - I2S" ---------------------------------------------------------------------------------------------------------------------------------- NOW PRESS ENTER in the 1st shell-Windows (.compile.sh) (on armbian-BuildSystem) ---------------------------------------------------------------------------------------------------------------------------------- -> Then script compilation will stop again to ask whether you want to add pcm5102a to compile -> Default is N, so you need to enter m for module compilation Texas Instruments PCM5102A CODEC - I2S (SND_SOC_PCM5102A) [N/m/?] (NEW) m = m for module compilation After compile is complete ---------------------------------------------------------------------------------------------------------------------------------- copy (via SCP/FTP?) the .deb's from /home/guido/build/output/debs (on armbian-BuildSystem) to /home/guido/ (on the NanoPi Neo) ---------------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------- INSTALL the .deb's (here only header and image - because it was already 5.67 (on NanoPi Neo) ---------------------------------------------------------------------------------------------------------------------------------- cd /home/guido dpkg -i ./linux-headers-next-sunxi_5.67_armhf.deb dpkg -i ./linux-image-next-sunxi_5.67_armhf.deb (image did include the .ko module for the pcm5102a) ---------------------------------------------------------------------------------------------------------------------------------- now REBOOT (on NanoPi Neo) ---------------------------------------------------------------------------------------------------------------------------------- ===================================================================================== ===================================================================================== !!!!!!!!!!!!!!!!!!!!!!!!!!!!! ATTENTION: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! After reboot my NanoPi Neo show the following armbian-version: ARMBIAN 5.65 stable Debian GNU/Linux 9 (stretch) 4.14.84-sunxi and 2 upgrades for headers&image (without the PCM5102A support) please keep in mind to freeze the kernel-updates in armbian-config for not to loose the support (module) for the PCM5120A! armbian-config -> system -> Freeze Disable kernel upgrades ===================================================================================== ===================================================================================== ---------------------------------------------------------------------------------------------------------------------------------- BE HAPPY about a successful i2s mapping in dmesg (on NanoPi Neo) ---------------------------------------------------------------------------------------------------------------------------------- root@npi-neo(192.168.6.24):~# dmesg|grep -i i2s [ 6.911751] asoc-simple-card sound_i2s: pcm5102a-hifi <-> 1c22000.i2s mapping ok ---------------------------------------------------------------------------------------------------------------------------------- I enabled also ananlog-Codec (on NanoPi Neo) ---------------------------------------------------------------------------------------------------------------------------------- root@npi-neo(192.168.6.24):/home/guido# aplay -l **** Liste der Hardware-Geräte (PLAYBACK) **** Karte 0: Codec [H3 Audio Codec], Gerät 0: CDC PCM Codec-0 [] Sub-Geräte: 1/1 Sub-Gerät #0: subdevice #0 Karte 1: I2Smaster [I2S-master], Gerät 0: 1c22000.i2s-pcm5102a-hifi pcm5102a-hifi-0 [] Sub-Geräte: 1/1 Sub-Gerät #0: subdevice #0 ---------------------------------------------------------------------------------------------------------------------------------- /etc/asound.conf (on NanoPi Neo) - later I2S did switch automatically to card 0 ---------------------------------------------------------------------------------------------------------------------------------- pcm.!default { type hw card 1 device 0 } ctl.!default { type hw card 1 } ---------------------------------------------------------------------------------------------------------------------------------- Reference-Threads ---------------------------------------------------------------------------------------------------------------------------------- config-default.conf.mod_nanopineo sun8i-h3-I2S-out.dts
  21. Hi, I've been running Octoprint on armbian for several months with good results of a couple of printers with good performance no relevant problems. Installation process is not complex but I decided to build a simple a plug&play meta-distribution like OctoPi for Rpi boards but based on armbian so it can be used potentially in any of the supported boards. I started with the popular Opi Zero as it is really cheap and the four cores of the H2+ processor handle perfectly a 3d printer load and is 3 times cheaper than a typical RPI3B that octoPi requires. You can find it here: https://github.com/ludiazv/octocitrico Built-in features are: Core (installed and enabled): Optimized armbian Debian buster. Latest stable octoprint version. Selection of top octoprint plugins. HAProxy with self signed keys for ssl access. Avahi service: Bonjur addvertisement (this enable to acces with host-name.local via ssh or http/s) SSH console access. USB OTG console access (if available in the board) Enabled i2c-dev,spidev (if available on the board) 3D printer related software (installed but disabled): Klipper PlatformIo core for building 3D printer firmware. Marlin 1.1.x & Marlin 2.x.x firmware (bugfix versions) Extras (installed but disabled): MPGStreamer USB camera support (experimental) SMB shares to remote edit configuration files from a remote PC. Feedback and contributions are welcome. Thanks armbian guys for the awesome work you do.
  22. Here are the instructions to run Htop remotely using a web browser. I often use Htop to monitor the health of my boards and servers (amd64). It is a good tool for the sys admin to monitor the servers in real-time without much resources and it is not very intrusive. Recipe 1 - Clone shellinabox root@cubieboard2:~# git clone https://github.com/shellinabox/shellinabox Cloning into 'shellinabox'... remote: Enumerating objects: 3073, done. remote: Total 3073 (delta 0), reused 0 (delta 0), pack-reused 3073 Receiving objects: 100% (3073/3073), 4.31 MiB | 1.89 MiB/s, done. Resolving deltas: 100% (2418/2418), done. root@cubieboard2:~# cd shellinabox/ 2 - Build and install shellinabox shellinabox makefile is outdated for OpenSSL 1.1.y, so we need to bypass the linking process and do it manually. During the config process you get some errors, bypass the error by doing like so: root@cubieboard2:~/shellinabox# apt-get install libtool root@cubieboard2:~/shellinabox# autoreconf -i root@cubieboard2:~/shellinabox# autoconf root@cubieboard2:~/shellinabox# autoreconf -i root@cubieboard2:~/shellinabox# ./configure root@cubieboard2:~/shellinabox# make 3 - Bypass the linking error During the link process you get a missing openssl 1.1 lib, we then manually link shellinabox: root@cubieboard2:~/shellinabox# gcc -g -std=gnu99 -Wall -Os -o shellinaboxd shellinabox/shellinaboxd.o shellinabox/externalfile.o shellinabox/launcher.o shellinabox/privileges.o shellinabox/service.o shellinabox/session.o shellinabox/usercss.o ./.libs/liblogging.a ./.libs/libhttp.a -ldl -lutil -lssl -lcrypto 4 - Running Htop on the Browser I choose not to install shellinabox, just run a service to be able to run and make Htop available on the Browser. Tested on Google Chromium and FireFox (linux). root@cubieboard2:~/shellinabox# ./shellinaboxd -t -b -p 8888 --no-beep -s '/htop_app/:alex:alex:/:htop -d 10' where 8888 is the port. alex:alex is the user:group to run Htop with. Use yours [user] and [group]. Note: for security reason if you run with nobody:nogroup you wont be able to add or change any config on the Htop. Now fire the browser at http://ip_address:8888/htop_app/ and that's it, enjoy. 5 - Credits stackverflow, user ofstudio. Screenshot:
  23. I got my hands on a "Set 9" Orange Pi Lite + GC2035 camera a while back and I've finally been able to put together a self-contained object detection device using Tensorflow, without sending any image data outside for processing. Basically, its a python Flask application that captures frames from the camera using a GStreamer pipeline. It runs them through a Tensorflow object detection model and spits out the same frame with extra metadata about objects it found, and renders a box around them. Using all four cores of the H2 it can do about 2-3 fps. The app keeps track of the count of all object types it has seen and exposes the metrics in prometheus format, for easy creation of graphs of what it sees over time with Grafana I'll explain some of the more interesting aspects of how I got this to work here in case anyone else wants to try to get some use out of this very inexpensive hardware, and I am grateful to the many posts on this forum that helped me along the way! Use a 3.4 kernel with custom GC2035 driver Don't bother with anything new - the GC2035 was hopeless on any newer builds of Armbian I tried. The driver available at https://github.com/avafinger/gc2035.git provided far better image quality. After installing the updated GC2035, I run the following to get the camera up and running: sudo sunxi-pio -m "PG11<1><0><1><1>" sudo modprobe gc2035 hres=1 sudo modprobe vfe_v4l2 Install Tensorflow lite runtime Google provides a tensorflow runtime as a binary wheel built for python 3.5 armv7. When pip installing, expect it to take 20 minutes or so as it will need to compile numpy (the apt repo version isn't recent enough) wget https://github.com/google-coral/pycoral/releases/download/release-frogfish/tflite_runtime-2.5.0-cp35-cp35m-linux_armv7l.whl sudo -H pip3 install tflite_runtime-2.5.0-cp35-cp35m-linux_armv7l.whl Build opencv for python 3.5 bindings This was something I tried everything I could to avoid, but I just could not get the colour conversion from the YUV format of the GC2035 to an RGB image using anything else I found online, so I was dependent on a single color-conversion utility function. To build the 3.4.12 version for use with python (grab lunch - takes about 1.5 hours :-O ) cmake -DCMAKE_INSTALL_PREFIX=/home/atomic/local -DSOFTFP=ON \ -DBUILD_TESTS=OFF -D BUILD_PERF_TESTS=OFF -D BUILD_opencv_python2=0 \ -D BUILD_opencv_python3=1 -D WITH_GSTREAMER=ON \ -D PYTHON3_INCLUDE_PATH=/usr/include/python3.5 .. make -j 4 make install # Check that ~/local/lib/python3.5/dist-packages should now have the cv2 shlib export PYTHONPATH=/home/atomic/local/lib/python3.5/dist-packages Build gstreamer plugin for Cedar H264 encoder This is required to get a working gstreamer pipeline for the video feed: git clone https://github.com/gtalusan/gst-plugin-cedar ./autogen.sh sudo make install # When trying against a pipc I had to copy into .local to get gstreamer to recognise it cp /usr/local/lib/gstreamer-1.0/libgst* ~/.local/share/gstreamer-1.0/plugins/ # Confirm that plugin is installed: gst-inspect-1.0 cedar_h264enc Processing images The full app source is on github, but the more interesting parts that took me some time to figure out were about getting python to cooperate with gstreamer: Frames from the camera arrive to python at the end of the pipeline as an appsink. The Gstreamer pipeline I configured via python was: src = Gst.ElementFactory.make("v4l2src") src.set_property("device", "/dev/video0") src.set_property("do-timestamp", 1) filt = Gst.ElementFactory.make("capsfilter") filt.set_property("caps", Gst.caps_from_string("video/x-raw,format=NV12,width=800,height=600,framerate=12/1")) p1 = Gst.ElementFactory.make("cedar_h264enc") p2 = Gst.ElementFactory.make("h264parse") p3 = Gst.ElementFactory.make("rtph264pay") p3.set_property("config-interval", 1) p3.set_property("pt", 96) p4 = Gst.ElementFactory.make("rtph264depay") p5 = Gst.ElementFactory.make("avdec_h264") sink = Gst.ElementFactory.make("appsink", "sink") pipeline_elements = [src, filt, p1, p2, p3, p4, p5, sink] sink.set_property("max-buffers", 10) sink.set_property('emit-signals', True) sink.set_property('sync', False) sink.connect("new-sample", on_buffer, sink) This pipeline definition causes a callback on_buffer to be called every time a frame is emitted from the camera: def on_buffer(sink: GstApp.AppSink, data: typing.Any) -> Gst.FlowReturn: # Sample will be a 800x900 byte array in a very frustrating YUV420 format sample = sink.emit("pull-sample") # Gst.Sample ... conversion to numpy array # rgb is now in a format that Pillow can easily work with # These two calls are what you compiled opencv for 1.5 hours for :-D rgb = cv2.cvtColor(img_arr, cv2.COLOR_YUV2BGR_I420) rgb = cv2.cvtColor(rgb, cv2.COLOR_BGR2RGB) Once you have a nice pillow RGB image, it's easy to pass this into a Tensorflow model, and there is tons of material on the web for how you can do things like that. For fast but not so accurate detection, I used the ssdlite_mobilenet_v2_coco pretrained model, which can handle about 0.5 frames per second per core of the H2 Allwinner CPU. There are some problems I still have to work out. Occasionally the video stream stalls and I haven't figured out how to recover from this without restarting the app completely. The way frame data is passed around tensorflow worker processes is probably not ideal and needs to be cleaned up, but it does allow me to get much better throughput using all four cores. For more details, including a detailed build script, the full source is here: https://github.com/atomic77/opilite-object-detect
  24. As a result of all the work that Armbian developers put into the upgrade to kernel 4.14 for the XU4 board family, now we can enjoy many new features. One of them is the access to the SoC video encoding capabilities. Emby Media Server can take advantage of the Exynos 5422 MFC video engine for transcoding. That means lower CPU usage, lower temperatures, and the possibility of encoding in real time higher resolutions or more simultaneous streams. In my tests, I've been able to transcode one HEVC 1080p and one 480p at the same time, or five 480p (though it will depend on the bitrate of the source material). However, the ffmpeg version shipped with official Emby is quite unstable when using this feature. For that reason, I compiled a better and more stable version from @memeka's repo. I've been using it for over a month without a single crash. So this is a step-by step guide on how to make everything work: 0. [PREREQUISITE]: You must be running an Armbian Strech XU4 "Next" image, like the one you can download here. >> DOWNLOAD the emby and ffmpeg packages from this link << Install them (Note: this will install Emby Server version 3.5.3, which is the last at the writing of this tutorial. It has been tested to work with this version, and may or may not work with any other): $ tar xvf emby-server-stretch-xu4_1.0.tar.xz $ sudo dpkg -i ffmpeg/*.deb $ sudo dpkg -i emby-server/*.deb $ sudo apt -f install Hold the ffmpeg packages, so they don't get upgraded: $ sudo apt-mark hold ffmpeg-doc ffmpeg libavcodec-dev libavcodec-extra libavdevice-dev libavfilter-dev libavfilter-extra libavformat-dev libavresample-dev libavutil-dev libmysofa-dev libmysofa-utils libmysofa0 libpostproc-dev libswresample-dev libswscale-dev Add the user "emby" to the video group, so it can have access to the transcoding engine: $ sudo usermod -aG video emby Modify the emby executable, to use our custom ffmpeg (Note: you will need to repeat this step every time you update the emby deb package): $ sudo nano /opt/emby-server/bin/emby-server # Change the following line: ffmpeg $APP_DIR/bin/ffmpeg \ # to: ffmpeg /usr/bin/ffmpeg \ Restart the service: $ sudo service emby-server restart Now, you can open the web browser, point to your Emby server (e.g. http://odroidxu4.local:8096), and configure it as described in the official tutorial (https://github.com/MediaBrowser/Wiki/wiki/Installation). For last, you need to enable Hardware video transcoding in the web interface. The option is under the "Transcoding" submenu. Don't forget to click on "Save" when you are done: And that's it! As an additional tip, I recommend disabling UPnP in Emby, because it causes the program to crash frequently when enabled (this is just a general recommendation, it has nothing to do with hardware encoding). Enjoy! And please, share your experiences and comments here.
  25. Maybe someone does know the old/historical SAM (Software Automatic Mouth) speech synthesizer for the Commodore 64? Today I did found the github-page with the source-code and compiled it on my Orange Pi R1 - using armbian For compiling the default SDL-version I had to install the 2 additional packages with apt - libsdl1.2-dev - libsdl1.2debian before SAM did compile on armbian. I also did try libsdl2-2.0.0 (and -dev), but this didnt worked well while compiling The souce-code could be found at: https://github.com/s-macke/SAM Hear here, how this OLD speech synthesizer sounds https://www.youtube.com/watch?v=Rm4ZCGgzeeU Test him ONLINE: https://simulationcorner.net/index.php?page=sam Or read about him in the Wikipedia: https://en.wikipedia.org/wiki/Software_Automatic_Mouth