• Posts

  • Joined

  • Last visited

Reputation Activity

  1. Like
    mar0ni reacted to MMGen in Full root filesystem encryption on an Armbian system (NEW, replaces 2017 tutorial on this topic)   
    Full root filesystem encryption on an Armbian system
    (new, fully rewritten, replaces my earlier tutorial on this topic)
    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
    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.
    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
    IP= 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/' 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/'  
    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@  
    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. Like
    mar0ni reacted to Igor in lightdm crashes after recent upgrade   
    Try perhaps this: 
    apt install slick-greeter + reboot.
  3. Like
    mar0ni reacted to 2020 in Linux OS with DRM enable & GPU hardware accelerated – How to   
    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 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 Latest Chrome version Download the user agents text file for the latest Chrome version with the platform Chrome OS
    ARMv7 (armhf / 32-bit) or 
    ARMv8 (arm64 / 64-bit) (use the highest version)  
    Vivaldi browser installation
     Download Vivaldi (
    ARMv7 (armhf / 32-bit) or
    ARMv8 (arm64 / 64-bit) 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: 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 widevine-flash
    ARMv8 (arm64 / 64-bit)
    git clone widevine-flash
    cd widevine-flash
    sudo sh ./ or sudo sh ./ (and follow the instructions) Open Vivaldi with the DRM browser launcher and check if DRM is working  
    Now you are ready to watch Netflix :-) Cheers!
  4. Like
    mar0ni reacted to TonyMac32 in Use GPIO on C2 with Mainline Kernel   
    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.
  5. Like
    mar0ni got a reaction from Igor in Latest armbian-zsh package broken?   
    Fixed by probably this commit and available with release v21.02.3.
  6. Like
    mar0ni reacted to Igor in 2021: Year of the Armbian Desktop!   
    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. 
    Finally, the time is right to announce we are publishing our initial implementation of these "desktop" features!

    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:
    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: ( 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:
    ./ 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:

    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:

    During this change we also added most recent userland(s):

  7. Like
    mar0ni reacted to Igor in Odroid C4, the system didn't boot with eMMc   
    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:
  8. Like
    mar0ni reacted to NicoD in RK3399 Legacy Multimedia Framework   
    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. 
  9. Like
    mar0ni got a reaction from jiko in PWM Fan on Nanopi M4 ??   
    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  
  10. Like
    mar0ni reacted to NicoD in Build Armbian with Panfrost (outdated)   
    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 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 sudo dpkg -i meson_0.55.3-1_all.deb Download and install mesa DRM
    git clone git:// cd drm meson build --prefix=/usr ninja -C build sudo -E ninja -C build install cd .. Download and install mesa graphics
    git clone git:// 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 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
  11. Like
    mar0ni reacted to Hover in Mainline u-boot spl nvme support   
    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( 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
  12. Like
    mar0ni got a reaction from gounthar in PWM Fan on Nanopi M4 ??   
    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  
  13. Like
    mar0ni reacted to araynard in PWM Fan on Nanopi M4 ??   
    Hello mar0ni,
    I'm trying your last script with a NanoPiM4v2, but bash gives me the following error:
    /usr/bin/ line 33: echo: write error: Invalid argument But I can't find the problem in your code.
    Any idea ?
    I had to add quotes around the file path:
    echo $DUTY > "/sys/class/pwm/pwmchip1/pwm0/duty_cycle"; It's working great now !
  14. Like
    mar0ni reacted to chwe in NanopiM4v2 booting. this is weird

    should explain most of it..
    this whole mess should be cleaned once we've moved all boards to upstream u-boot for rk3399 boards...
  15. Like
    mar0ni reacted to JMCC in [Development] RK3399 media script   
    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.
  16. Like
    mar0ni reacted to hexdump in [Development] RK3399 media script   
    @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
  17. Like
    mar0ni got a reaction from justin.wills in PWM Fan on Nanopi M4 ??   
    Hi Justin, thank you for the hint, worked like a charm for me also.
    Attached the service file and bash script.
  18. Like
    mar0ni reacted to justin.wills in PWM Fan on Nanopi M4 ??   
    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
  19. Like
    mar0ni got a reaction from NicoD in Video : NanoPi M4 storage speed tests   
    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
  20. Like
    mar0ni reacted to Sir Lazarus in NanoPI M4   
    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] 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.