mar0ni

Slightly improved and simplified script (still room for improvement, I guess).
 
#!/bin/bash if [ ! -d /sys/class/pwm/pwmchip1/pwm0 ]; then echo 0 > /sys/class/pwm/pwmchip1/export fi sleep 1 while [ ! -d /sys/class/pwm/pwmchip1/pwm0 ]; do sleep 1 done ISENABLE=`cat /sys/class/pwm/pwmchip1/pwm0/enable` if [ $ISENABLE -eq 1 ]; then echo 0 > /sys/class/pwm/pwmchip1/pwm0/enable fi echo 50000 > /sys/class/pwm/pwmchip1/pwm0/period echo 1 > /sys/class/pwm/pwmchip1/pwm0/enable # max speed run 5s echo 0 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle sleep 5 echo 49994 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle declare -a CpuTemps=(75000 63000 58000 52000 48000 0) declare -a PwmDutyCycles=(25000 37000 48300 49250 49300 49994) while true do temp=$(cat /sys/class/thermal/thermal_zone0/temp) for i in 0 1 2 3 4 5; do if [ $temp -gt ${CpuTemps[$i]} ]; then DUTY=${PwmDutyCycles[$i]} echo $DUTY > "/sys/class/pwm/pwmchip1/pwm0/duty_cycle"; #echo "temp: $temp, target: ${CpuTemps[$i]}, duty: $DUTY" break fi done sleep 2s; done  

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, an 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 (the “target device”).
 
If the board has an eMMC, it may be used as the target device instead of an SD card. Depending on your platform, you may need to run “armbian-config” and select “Install to internal storage” -> “Install/Update the bootloader on eMMC” to enable booting from the eMMC.
 
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 package
 
# apt update && apt upgrade # apt install cryptsetup  
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 target device
 
If applicable, insert a blank micro-SD card and card reader into a USB port.
 
Determine the target 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 be something like '/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 target device, 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 target device
 
# 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 target device
 
The following commands will create a filesystem on the target device’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 will be something like '/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:
If the file 'boot/armbianEnv.txt' exists, edit it 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 If your image lacks an 'armbianEnv.txt' file, you’ll need to edit the file 'boot/extlinux/extlinux.conf' instead. All changes will be made to the line beginning with “append”. Alter the argument beginning with “root=” so that it reads “root=/dev/mapper/rootfs”. If you’ll be unlocking the disk via the serial console, remove the “console=tty1” argument. If not, remove the argument beginning with “console=ttyS...”. Replace the “splash plymouth...” argument with “splash=verbose”. Make sure to read the note about unlocking via serial console in the previous step.
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::end0:off If the board will be configured via DHCP, then edit the DEVICE line as follows:
DEVICE=end0 If your default network device is eth0, use that instead of end0.
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/dropbear.conf # echo 'DROPBEAR=y' >> etc/dropbear/initramfs/dropbear.conf  
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  
Now regenerate your SSH host keys:
# ssh-keygen -A  
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!

Try perhaps this: 
apt install slick-greeter + reboot.

This tutorial is based on my knowledge and experience in testing Tinkerboard. It has not been tested on other devices and I do not take any responsibility nor am I liable for any damage that may be caused through the use of this tutorial.
 
Debian / XFCE minimal desktop
Download the latest current version of Bullseye (Panfrost drivers included) for your device and follow the instructions 
https://www.armbian.com/download/ After the first login type ... 
exit (exit from root, login with your new user id)
sudo apt update
sudo apt upgrade (if the kernel installation prompts for modifications, just say Yes or Ok)
sudo apt install task-xfce-desktop xfce4-terminal firefox-esr network-manager-gnome gparted
sudo reboot Login graphically with your user id ...
Open Firefox and check if you have access to internet Open xfce terminal and add the basic xfce packages
sudo apt install pulseaudio pavucontrol gvfs gvfs-backends policykit-1 udisks2 catfish mousepad xarchiver gdebi gigolo
sudo reboot  
Find out ...
ARM architecture of your computer processor
https://en.m.wikipedia.org/wiki/List_of_ARM_microarchitectures Latest Chrome version
https://www.google.com/search?q=The+latest+user+agents+for+Chrome&oq=The+latest+user+agents+for+Chrome&aqs=chrome..69i57j69i60l3&sourceid=chrome&ie=UTF-8 Download the user agents text file for the latest Chrome version with the platform Chrome OS
ARMv7 (armhf / 32-bit)
https://user-agents.net/download?browser=chrome&version=87-0&browser_bits=32&platform=chromeos&platform_bits=32&name=armv7l or 
ARMv8 (arm64 / 64-bit)
https://user-agents.net/download?browser=chrome&version=87-0&platform=chromeos&name=aarch64 (use the highest version)  
Vivaldi browser installation
 Download Vivaldi (https://vivaldi.com/download/archive)
ARMv7 (armhf / 32-bit)
https://downloads.vivaldi.com/stable/vivaldi-stable_3.4.2066.106-1_armhf.deb or
ARMv8 (arm64 / 64-bit)
https://downloads.vivaldi.com/stable/vivaldi-stable_3.4.2066.106-1_arm64.deb Open GDebi and install your specific Vivaldi browser  
Create a desktop launcher
Name: DRM browser Command: /usr/bin/vivaldi-stable --disable-seccomp-filter-sandbox --user-agent="Mozilla/5.0 (X11; CrOS armv7l 13505.40.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.54 Safari/537.36"
 *** Use the latest user agents text string ***  
Open Vivaldi with the DRM browser launcher and verify the parameters ...
user agent: https://whatmyuseragent.com components: vivaldi://components (check if Widevine Content Decryption Module is loaded) gpu:  vivaldi://gpu flags:  vivaldi://flags Enable > Override software rendering list  
Widevine-flash installation
Close any opened Vivaldi Browser  Open xfce terminal and download the script that fetches a ChromeOS image and extracts the Widevine and Flash
ARMv7 (armhf / 32-bit)
git clone https://gist.github.com/e025024ecffa45ee4325a3915fd8dad1.git widevine-flash
ARMv8 (arm64 / 64-bit)
git clone https://gist.github.com/7e1e1c313843d6a8180cfc1f47bee6aa.git widevine-flash
cd widevine-flash
sudo sh ./widevine-flash_arm32.sh or sudo sh ./widevine-flash_arm64.sh (and follow the instructions) Open Vivaldi with the DRM browser launcher and check if DRM is working
https://bitmovin.com/demos/drm  
Now you are ready to watch Netflix :-) Cheers!

Hmm, The odroid-N1 is an RK3399 board, maybe that's what's killing the gpio library.  Or the header may be irrelevant, I honestly don't know. 
 
The GPIO on the Amlogic devices is quite a bit different.  I don't vary from the stock device tree most of the time, so other than the spidev I added it will reflect (assuming I read the schematic correctly, and it in turn was correct)
 

 
I've been meaning to do it for some time, but I'm just starting working on documenting some of the GPIO's and their various functions.  So, in the device tree if you enable UART A, you'd have the port you want.  Unfortunately my wizardry does not include device tree overlays yet, however this may be something that's ok out of the box if the vendor image has it configured.  (clarification:  I can make a static change to the device tree, however for these sorts of things dynamic changes via overlays is better)
 
It's also good to see @adafruit doesn't sleep either.  However, I will be going, back to paid work in 6 hours.

Fixed by probably this commit and available with release v21.02.3.

Armbian have historically been much more geared towards "server/headless" usage, for many different reasons.  It has taken a much longer time not only for upstream development of underlying graphical libraries / drivers to mature, but also for us (the Armbian project itself) to come up with a sensible implementation that would fit nicely into our existing build framework.
 
However, this work has been going on in the background for quite some time already. 
 
Announcement
 
Finally, the time is right to announce we are publishing our initial implementation of these "desktop" features!
 
Warning!

We are only announcing this here on our own forums for the time being, as this is still early days.  In fact, at this point we are still mainly looking for testers. You should consider this an alpha quality release at this time!
 
What works so far?

Features we plan to develop works, we are already hunting bugs for months, but they are certainly still present. Remember, we are not looking for bugs that are tied to specific hardware feature, but bugs that are linked to the build process, userland and basic desktop functionality. 
 
Report bugs in Armbian build framework section: https://forum.armbian.com/forum/12-armbian-build-framework/
 
Currently, the following Desktop Environments (DEs) are considered to have early "support":
 

 

 
In addition, there are more DEs which should be considered very much WIP, in other words, not really fully working (yet), but we designed a system that can have unlimited variants.
 
Help Wanted!
 
These changes are wide ranging and touch many parts of the code.  Therefore even if you don't plan on using any "desktop" features, your testing can help to find bugs, even in "server" versions (as eventually this code will be merged with master in matter of weeks).
 
If you have been looking for some opportunity to help the project by getting involved a bit more, this could be your chance!

When you notice a problem make a pull request: https://github.com/armbian/build/pulls ( currently sits on a branch "desktop" )
 
Going forward we will be looking for additional desktop maintainers.  Currently the plan is for the Armbian core team to maintain the framework and perhaps settle on 2-3 DE options.  Any which are to be considered in addition to that, will need to come with some commitment to ongoing maintenance by whoever is interested in those additional desktops.
 
Join #armbian-devel IRC channel for development level chat and strengthen the desktop team. Welcome!
 
Getting Started
 
If this is your very first time using the build scripts, start with general instructions. If you are already familiar with the basics of building, some additional detailed instructions pertaining to desktop features can be found here.  You will also need to add:
 
./compile.sh LIB_TAG=desktop EXPERT=yes  
If you don't have option or desire to build from sources, you can also check if your board has nightly images - we are compiling them from this new development branch for a few weeks now - for the desktop you want to try / see:


 
Documentation
 
For end users, if you just want to build image interactively and by choosing supported OS variants, things hasn't changed much and should just work while advanced documentation has changed significantly. Its pretty much WIP and is scattered around in those files:
 
https://github.com/armbian/build/blob/desktop/config/desktop/README.md
https://github.com/armbian/documentation/pull/125
https://github.com/armbian/documentation/pull/98
 
Additional
 
During this change we also added most recent userland(s):
 

Armbian is (probably) the the only distribution that doesn't use u-boot from 2015. All others are still using stock private Hardkernel boot loader ... We try to get rid of vendors dirty security hazardous code as soon as possible and problems as such is the price that we need to pay.
 
Currently we use u-boot based on 2020.xx, but it looks like it's possible that we need the one from 2021 as this is the case with C2. Some eMMC needs this. Mine obviously don't since it works without any intervention.
Try this image:
https://users.armbian.com/igorp/images/Armbian_21.02.0-trunk_Odroidc4_focal_current_5.10.12.img.xz

I finished the video about the media script. 
I had a lot of troubles with youtube because I used a few seconds of southpark and I got age restriction 18 years. Youtube doesn't like Southpark clearly. 
Tried 3 times with different clips. In the end I cut it all out.. Thanks @JMCC for the awsome work. Without your scripts I wouldn't think of using an SBC as main desktop. 
 

Slightly improved and simplified script (still room for improvement, I guess).
 
#!/bin/bash if [ ! -d /sys/class/pwm/pwmchip1/pwm0 ]; then echo 0 > /sys/class/pwm/pwmchip1/export fi sleep 1 while [ ! -d /sys/class/pwm/pwmchip1/pwm0 ]; do sleep 1 done ISENABLE=`cat /sys/class/pwm/pwmchip1/pwm0/enable` if [ $ISENABLE -eq 1 ]; then echo 0 > /sys/class/pwm/pwmchip1/pwm0/enable fi echo 50000 > /sys/class/pwm/pwmchip1/pwm0/period echo 1 > /sys/class/pwm/pwmchip1/pwm0/enable # max speed run 5s echo 0 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle sleep 5 echo 49994 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle declare -a CpuTemps=(75000 63000 58000 52000 48000 0) declare -a PwmDutyCycles=(25000 37000 48300 49250 49300 49994) while true do temp=$(cat /sys/class/thermal/thermal_zone0/temp) for i in 0 1 2 3 4 5; do if [ $temp -gt ${CpuTemps[$i]} ]; then DUTY=${PwmDutyCycles[$i]} echo $DUTY > "/sys/class/pwm/pwmchip1/pwm0/duty_cycle"; #echo "temp: $temp, target: ${CpuTemps[$i]}, duty: $DUTY" break fi done sleep 2s; done  

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

I want to use the mainline u-boot spl to load the u-boot proper(u-boot.itb) from nvme, so that the only part off the nvme is the tpl/spl in the emmc/sd/spi flash.
But now the mainline u-boot has no pcie driver and no nvme support in spl.
 
I have found the radxa guys using their u-boot in spi flash to boot kernel from nvme. But their pcie driver(https://github.com/radxa/u-boot/commit/096f2c16bbfa24c93a4c87e31334d5b5064dfd0a) has a limitation: It can not be used in u-boot spl, or it would not function properly in u-boot proper and fail the boot. 
After some frustrating tryings and compare with the linux driver, I found that the port initialization process was short cutted and causing the reinitialization malfunctioned. After this correction the pcie driver can be used in spl: it can be reinitialized correctly in u-boot proper.
 
Bring nvme support into spl is just a mimic from the spl_mmc and spl_usb driver.
 
Another patch for fixing spl_ext as I want the u-boot.itb and kernel in a ext4 partition on nvme but the existing spl_ext can not load the u-boot.itb properly.
 
With these patches I can boot nanopc-t4 with u-boot.itb and linux kernel in nvme boot partition and only the u-boot tpl/spl in emmc.
 
Btw, now the vidconsole of the mainline u-boot is working on rk3399, but usb phys are still missing.
 
 
pcie.patch rk3399_boot_nvme.patch spl_ext_fix.patch spl_nvme.patch

Slightly improved and simplified script (still room for improvement, I guess).
 
#!/bin/bash if [ ! -d /sys/class/pwm/pwmchip1/pwm0 ]; then echo 0 > /sys/class/pwm/pwmchip1/export fi sleep 1 while [ ! -d /sys/class/pwm/pwmchip1/pwm0 ]; do sleep 1 done ISENABLE=`cat /sys/class/pwm/pwmchip1/pwm0/enable` if [ $ISENABLE -eq 1 ]; then echo 0 > /sys/class/pwm/pwmchip1/pwm0/enable fi echo 50000 > /sys/class/pwm/pwmchip1/pwm0/period echo 1 > /sys/class/pwm/pwmchip1/pwm0/enable # max speed run 5s echo 0 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle sleep 5 echo 49994 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle declare -a CpuTemps=(75000 63000 58000 52000 48000 0) declare -a PwmDutyCycles=(25000 37000 48300 49250 49300 49994) while true do temp=$(cat /sys/class/thermal/thermal_zone0/temp) for i in 0 1 2 3 4 5; do if [ $temp -gt ${CpuTemps[$i]} ]; then DUTY=${PwmDutyCycles[$i]} echo $DUTY > "/sys/class/pwm/pwmchip1/pwm0/duty_cycle"; #echo "temp: $temp, target: ${CpuTemps[$i]}, duty: $DUTY" break fi done sleep 2s; done  

Hello mar0ni,
I'm trying your last script with a NanoPiM4v2, but bash gives me the following error:
/usr/bin/start-rk3399-pwm-fan-v2.sh: line 33: echo: write error: Invalid argument But I can't find the problem in your code.
Any idea ?
 
EDIT:
I had to add quotes around the file path:
echo $DUTY > "/sys/class/pwm/pwmchip1/pwm0/duty_cycle"; It's working great now !

https://github.com/armbian/build/blob/9be143c2e4788deae6faf26d8ecfd921cfd52deb/patch/u-boot/u-boot-rk3399/add-board-nanopi-m4v2.patch#L29
 
https://lists.denx.de/pipermail/u-boot/2017-April/285942.html
 
should explain most of it..
 
this whole mess should be cleaned once we've moved all boards to upstream u-boot for rk3399 boards...

Yes, it is a known issue with glamor, that instead of "accelerating" it slows down certain 2D operations. In the case of Rockchip's modified glamor to work with OpenGL-ES, It is even worse. It is the trade-off for having the possibility of an accelerated canvas for 3D, video playing, browser, etc.
 
However, in the mainline kernel and current X server, they are tweaking glamor to be much more efficient. Hopefully we can see a stable version soon.

@mar0ni - yes this is normal behaviour i think as there is some inefficient memory copying happening between the gpu and the x server and there is no proper 2d acceleration (used for such window moves) around ... but i guess @JMCC can explain it in more detail ...
 
best wishes - hexdump

Hi Justin, thank you for the hint, worked like a charm for me also.
 
Attached the service file and bash script.
pwm-fan.tar.bz2

I just copied the pwm-fan.service and associated script from the friendly distro.  can't remember the name, rk3399-something, but it is defined in the service file

At the weekend, I tested the 64GB eMMC module and here are the results, just for the records
64GB eMMC module read : 180 MB/s write : 165 MB/s ... and also a Samsung 970 Evo Plus (500GB) with an amazing write speed of 730 MB/s
500GB 970 Evo Plus read : 736 MB/s write : 730 MB/s

It seems, that there is no driver for fan in armbian. So I wrote a little program in C to control fan on the hat. This nice program adjust the fan speed on cpu temperature accordingly. It starts the fan as 60 °C with 30% power. At 70 °C up to 60% and at 80 °C to 90%. You can adjust it within the code easily.
Compile it with "gcc fancontrol.c -o fancontrol". I configured the program as service. If you want it too, do the following steps:
Create a file fancontrol.service with the following content:
[Unit] Description=Fan control [Service] Type=simple User=root Group=root WorkingDirectory=/usr/bin ExecStart=/usr/bin/fancontrol [Install] WantedBy=multi-user.target do the following steps
sudo cp fancontrol /usr/bin sudo cp fancontrol.service /etc/systemd/system sudo systemctl enable fancontrol sudo systemctl start fancontrol  and that's it.
It works perfekt for me.
Have fun.