kernel: NVRM: GPU 0000:01:00.0: Failed to copy vbios to system memory.
kernel: NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x30:0xffff:663)
kernel: NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0

After installing various (known to work previously) distributions, killing my bootloader in the process (yeah, thanks UEFI) I got desperate and installed Windows 10. The card showed up with a yellow exclamation mark in the device manager, stating the card couldn’t be used because it failed starting up with „Error 43“.

Some googling suggested to try the card in another motherboard, but I was afraid that would have been a bit much for an integrated graphics card. After some more googling, I tried to use „nvflash64“ – first with the wrong bios (fortunately, nvflash refused to flash the wrong image and yielded the ID I needed to search for the right one). I found the vbios file at techpowerup. Flashed the right file and… The exclamation mark was gone! Subsequently, when I restored my linux partition (an adventure of its own, due to my stupidity), NVIDIA Settings is working again! Yay!

Problem is, the webcam is not recognized by Skype for Business (using the Citrix HDX RT Media Engine), cheese or Microsoft Teams for Linux.

I found the reason – those programs only support YUY2 color formats, while the webcam (and other solutions, like droidcam) supply other formats. Solution:

1. Install v4l2loopback from git
2. Create a loopback video device by loading the module
3. Start a gstreamer pipline to convert the color space

For my quickcam chat, it looks like this:

gst-launch-1.0 -v v4l2src device=/dev/video2 ! video/x-bayer ! bayer2rgb ! videobalance saturation=0.8 ! videoconvert ! video/x-raw,format=YUY2 ! v4l2sink device=/dev/video4

/dev/video2 being the device of the webcam, /dev/video4 being the loopback device created earlier by loading the loopback module.

The loopback module has to be started with more than default buffers:

sudo modprobe v4l2loopback max_buffers=16

An example for droidcam (droidcam being /dev/video3):

gst-launch-1.0 -v v4l2src device=/dev/video3 ! smooth ! videoconvert ! video/x-raw,format=YUY2 ! v4l2sink device=/dev/video4

You will need:

• a Pinebook Pro
• an SD Card (at least 8GB)
• patience

DISCLAIMER

These instructions are potentially able to brick your device. There are (somewhat painful) ways to get back from a bricked Pinebook Pro (using the RockChip Flash Tool or the UART console). So, if you never compiled a kernel and actually gotten to start it, you might want to refrain from following this guide.

Setting up the SD card

First, I acquired the original Debian image here: https://github.com/mrfixit2001/debian_desktop/releases/download/190905/pinebookpro-debian-desktop-mrfixit-190905.img.xz.

This needs to be decompressed and „flashed“ to your SD card (careful!). Be sure to use the right device, otherwise you might end up bricking your Pinebook Pro…

xz -d pinebookpro-debian-desktop-mrfixit-190905.img.xz

sudo dd if=pinebookpro-debian-desktop-mrfixit-190905.img of=/dev/mmcblk0
sync

Eject and insert the SD card.

sudo mount /dev/mmcblk0p1 /mnt/
nano /mnt/extlinux/extlinux.conf

Make sure it says
root=/dev/mmcblk1p2
in line #8 – this will load the kernel from SD, but set the root to your EMMC (interal) drive.

Reboot and make sure your device boots up normally. If you already did the update before, you will see that your kernel version now („uname -a“) should be 4.4.190 instead of the updated 4.4.196 on your internal drive.

Setting up the build environment

For this, we will use Debian „Buster“ on your pinebook pro. How? By using snap & lxd!

sudo apt install snapd
sudo snap install lxd
sudo /snap/bin/lxd init

Accept all defaults BUT for the storage pool – set up a new pool with storage backend „dir“.

Once that’s done, set up a new Debian Buster container:

sudo /snap/bin/lxc launch images:debian/buster myvm

Depending on your internet connection, this takes a while. Once that’s done, we’re ready to use the container:

sudo /snap/bin/lxc exec myvm /bin/bash

Now you’re in a shell in your container. First, you want to install some packages:

apt-get install crossbuild-essential-arm64 libncurses-dev git bc ccache nano

The kernel is an aarch64-kernel, the system is armhf however – that’s why we’re installing a cross compiler (credits). Edit your ~/.bashrc and add

export PATH="/usr/lib/ccache:$PATH"

At the bottom, then do

. ~/.bashrc

That should speed up compilation dramatically.

Use the source!

Make a new directory for your linux kernel, i.e. mkdir ~/src. Change to that directory cd ~/src and download the kernel sources of your choice, i.e.
git clone https://github.com/mrfixit2001/rockchip-kernel.git linux

Copy the existing kernel configuration to your source tree:

zcat /proc/config.gz ~/src/linux/.config
cd ~/src/linux/
make oldconfig

Almost set to go!

make menuconfig

Do your changes, save… now, compile the kernel:

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j 6 bindeb-pkg

And the device tree afterwards:

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j 6 rockchip/rk3399-pinebookpro.dtb

Log off from your container by using CTRL-D (or the method of your liking). The kernel is now in (with my names):

/var/snap/lxd/common/lxd/containers/myvm/rootfs/root/src

We’re going to install this and move it carefully. Make sure /boot/ isn’t mounted:

sudo umount /boot
sudo mount /dev/mmcblk0p1 /mnt/
sudo dpkg -i --force-architecture /var/snap/lxd/common/lxd/containers/myvm/rootfs/root/src/linux-image-4.4.196-gb9a54c00f_4.4.196-gb9a54c00f_arm64.deb
(or whatever .deb you just created).

cp /mnt/rk3399-pinebookpro.dtb /mnt/rk3399-pinebookpro.dtb.bak

cp /var/snap/lxd/common/lxd/containers/myvm/rootfs/root/src/linux/arch/arm64/boot/dts/rockchip/rk3399-pinebookpro.dtb /mnt/

Copy the kernel to SD card:

cp /boot/vmlinuz-4.4.196-gb9a54c00f /mnt/Image

Done! Reboot…

Yes, I know that there are LXD Api functions to work with container files, and working as root is not advised. But for the time being, it „works for me™“.

I’m switching to using xubuntu-desktop, since the new Ubuntu standard desktop combines the flaws of gnome3 with the flaws of Ubuntus desktop user interface.

Recently, the xrdp server stopped working. Looking for ways to fix it didn’t yield a proper result. I finally found the solution:

Due to upgrading my ubuntu server installation by using „do-release-upgrade“, an old libglib-2.0.0 was left over in /lib/x86_64-linux-gnu/ (version 4800.0). That library took priority over the new installed version in /usr/lib/x86_64-linux-gnu/ (version 5600.1). The error I saw was

„undefined symbol: g_date_copy“

After deleting /lib/x86_64-linux-gnu/libglib* and doing „apt –reinstall install libglib2.0-0“, I am able to log in to xfce4 again.

The cumulative effect of all those little ratchets on your privacy is rather terrible, but there is no denying it: you were along for the ride and you had the option to ‘opt out’ at every step. Not just from that one dialogue: from all of them by refusing to use products that are fielded by companies that engage in these unethical practices. Say no to ‘The Ratchet’ and it’s sick family of dark patterns designed to little-by-little chip away at your privacy, kick products and companies like that to the kerb where they belong. That’s the only way to really opt out.

Quelle: Dark Patterns, The Ratchet · Jacques Mattheij

Dark Patterns ist sowieso ein interessantes Blog, dass „dunkle Patterns“ beschreibt, also Benutzeroberflächen und Prozesse, die so gestaltet sind, dass der Nutzer etwas zustimmt, dem er/ sie eigentlich nicht zustimmen will…

Die neuen Dienstleistungsbedingungen von Microsoft für Services wie Skype, Xbox Live, Bing, Cortana oder Cloud-Angebote untersagen beleidigende Äußerungen. Auch Pornos und explizite Gewaltdarstellungen sind künftig tabu.

heise

Google löscht Pornos oder das, was sie dafür halten, Microsoft macht Moralfilter als Service. Dit is halt cloud.

Tip: We recommend using only one user account to manage both personal and professional repositories.

Quelle: Merging multiple user accounts – User Documentation

Yes, and I am quite fond of finding out how my clients react to having „MasterCoder69“ contributing to their GitHub hosted internal repositories…