RussianNeuroMancer

I didn't tried this on R2S specifically, but if it works inside systemd-nspawn - then it should work on headless SBC too.
 
1. Install Mate or XFCE via tasksel
2. Install gdm3 and tigervnc-standalone-server
3. Create these two files (don't forget to enable socket) and configure gdm3.
 
This is of course not only option - you can find other ways to get TigerVNC or xrdp works on headless system. I just told you what works for me, that it.

I can understand that you are disappointed.
 
But I think that Kobol had to pull the plug, in the context of the current chip shortage - with limited (sometimes even no) availability of components and SOCs and rising prices. That is not the right environment for a small start-up to grow. - it is a rather toxic environemnt that will lead to insolvency, as profitable growth is impossible to achieve. Without growth (no new/further products to offer) you are just faced with fixed costs and without income. Not sustainable at all.
 
All three of the founding members of Kobol deserve our full respect. They only drew a logical conclusion. Hopefully it can be reversed some time.

Hi,
 
I wanted to convert my root filesystem to btrfs.  This allows me to use snapper to take regular snapshops.  I also use btrbk to send my snapshots to my secondary storage (also a btrfs array).  My root filesystems is installed to eMMC, but there isn't any reason you couldn't do this with an sd card.  These instructions are done with a laptop running Linux.  I'm using Debian in this case, although any distro with a recent kernel and btrfs tools installed should work.
 
CAVEATS:
The current u-boot image (2020.08.21) doesn't support booting natively to btrfs.  u-boot *does* support btrfs though.  Hopefully a future build of u-boot will add btrfs support.  To work around this, we have to create an ext4 /boot partition, and then a btrfs root partition.
 
1. To start, I booted the helios64 via sd card to the USB mass storage image (https://wiki.kobol.io/helios64/install/emmc/).  I then connected a laptop to the helios64 via the USB-C cable, and the emmc appeared as /dev/sdb.  The rest of these instructions will assume the eMMC is /dev/sdb, so please adjust accordingly for your system.
 
2. Mount the eMMC root filesystem on the host:
# mkdir /mnt/nasrootext4 # mount /dev/sdb1 -o ro /mnt/nasrootext4  
3. Back up the contents of the root filesystem:
# tar -C /mnt/nasrootext4 --acls --xattrs -cf root_backup.tar .  
4. Make a backup of the partition layout (in case you decide to revert this modification):
# fdisk -l /dev/sdb | tee nas_fdisk.txt  
5. Unmount the filesystem, and run fdisk on it.  Make note of the start sector.  It should be 32768.
# umount /dev/sdb1 # fdisk /dev/sdb Command (m for help): p Disk /dev/sdb: 14.6 GiB, 15634268160 bytes, 30535680 sectors Disk model: UMS disk 0 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x794023b5 Device Boot Start End Sectors Size Id Type /dev/sdb1 32768 30230303 30197536 14.4G 83 Linux  
6. Delete the existing partition ('d')
7. Create a new partition ('n')
8. Select 'primary' partition type
9. Select partition number 1
10. Select first sector: 32768 (This is very important to get right, and should match the start sector of the partition that was just deleted)
11. Select last sector: +512M (this create a 512MB /boot partition)
12. You will see a message "Partition #1 contains a ext4 signature.".  This is okay.  I selected 'n' (don't remove signature) but it doesn't matter.  You should probably remove the signature since we're going to create a new ext4 filesystem anyway.
13. Create new partition ('n')
14. Select 'primary' partition type
15. Select partition number 2
16. First sector: 1081344 (this is one more than the end sector of the other partition)
17. Last sector: (leave the default as the full drive, 30535679 in my case)
18. Print the layout to confirm:
Disk /dev/sdb: 14.6 GiB, 15634268160 bytes, 30535680 sectors Disk model: UMS disk 0 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x794023b5 Device Boot Start End Sectors Size Id Type /dev/sdb1 32768 1081343 1048576 512M 83 Linux /dev/sdb2 1081344 30535679 29454336 14G 83 Linux  
19. Write the partition table to disk and exit ('w')
20. Create a new ext4 filesystem on the first partition: 'mkfs.ext4 /dev/sdb1' (you may need to add -F if it complains about an existing ext4 signature)
21. Create a new btrfs filesystem on the second partition: 'mkfs.btrfs /dev/sdb2'
22. Mount the new root filesystem:
# mkdir /mnt/nasrootbtrfs # sudo mount -o compress=zstd /dev/sdb2 /mnt/nasrootbtrfs  
23. Make some initial subvolumes (note that '@' will be the root subvolume, as this is preferred by 'snapper'):
# cd /mnt/nasrootbtrfs # btrfs subvol create @ # btrfs subvol create @home # btrfs subvol create @var_log  
24. Mount the boot partition, and the @home and @var_log subvolumes
# cd @ # mkdir boot # mount /dev/sdb1 boot/ # mkdir home # mount /dev/sdb2 -o noatime,compress=zstd,subvol=/@home home # mkdir -p var/log # mount /dev/sdb2 -o noatime,compress=zstd,subvol=/@var_log var/log # mount | grep sdb /dev/sdb2 on /mnt/nasrootbtrfs type btrfs (rw,relatime,compress=zstd,space_cache,subvolid=5,subvol=/) /dev/sdb1 on /mnt/nasrootbtrfs/@/boot type ext4 (rw,relatime) /dev/sdb2 on /mnt/nasrootbtrfs/@/home type btrfs (rw,noatime,compress=zstd,space_cache,subvolid=258,subvol=/@home) /dev/sdb2 on /mnt/nasrootbtrfs/@/var/log type btrfs (rw,noatime,compress=zstd,space_cache,subvolid=260,subvol=/@var_log)  
25. Note that our current directory is '/mnt/nasrootbtrfs/@'
26. Untar the old root filesystem into the new root directory.  Since boot, home, and var/log are mounted, tar will extract the relevant data into these mounted filesystems.
# tar -xvf /root/helios64_root.tar --acls --xattrs --numeric-owner |@ tee /root/extract_log.txt This is the only spot where things did not go as expected.  I received a handful of errors about "No space left on device" while untarring.  These seem to be transient btrfs errors. I use btrfs pretty extensively at work, and I've seen cases in the past on older kernels where btrfs would falsely report ENOSPC when the filesystem was under heavy load.  I'm not sure if that is what is happening here, but I would guess it's a bug.  It could be a bug in the kernel on my laptop, or it could be a bug in the usb-c mass storage export on the helios64.  To recover from this, I ran the tar command a couple of times.  I continued to receive these errors on different files.  I did this three or four times.  I also tried removing --acls and --xattrs, but it didn't seem to make much of a difference.  On my last attempt to untar, all of the files that failed happened to be from usr/lib/python3, so I untarred just that directory: 'tar -xvf /root/helios64_root.tar --numeric-owner ./usr/lib/python3'.  That extracted without error.  I was satisfied that everything made it back on disk.  Perhaps if you only extracted one top-level directory at a time, it would not produce any errors.  Maybe there is some way to slow down the 'tar' to avoid these ENOSPC errors.
 
27. After extracting the root filesystem, I made a snapshot of it: 'btrfs subvol snap -r . root_post_copy'
28. Update /mnt/nasrootbtrfs/@/etc/fstab.  This was my old fstab:
Old version: UUID=dabb3dbf-8631-4051-a032-c0b97eb285bd / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 tmpfs /tmp tmpfs defaults,nosuid 0 0 # >>> [openmediavault] /dev/disk/by-label/helios64_btrfs_raid1 /srv/dev-disk-by-label-helios64_btrfs_raid1 btrfs defaults,nofail,noatime,nodiratime,compress=zstd 0 2 # <<< [openmediavault]  
Look up the new UUID for /dev/sdb2.  I did this by running 'ls -l /dev/disk/by-uuid').  Updated /etc/fstab:
UUID=240bab7d-1b6c-48f4-898d-ba12abcecb3f / btrfs defaults,noatime,compress=zstd,ssd,subvol=@ 0 0 UUID=240bab7d-1b6c-48f4-898d-ba12abcecb3f /home btrfs defaults,noatime,compress=zstd,ssd,subvol=@home 0 0 UUID=240bab7d-1b6c-48f4-898d-ba12abcecb3f /var/log/ btrfs defaults,noatime,compress=zstd,ssd,subvol=@var_log 0 0 UUID=fd5b620c-57e2-4031-b56c-3c64ce7c7d5f /boot ext4 defaults,noatime 0 2 tmpfs /tmp tmpfs defaults,nosuid 0 0 # >>> [openmediavault] /dev/disk/by-label/helios64_btrfs_raid1 /srv/dev-disk-by-label-helios64_btrfs_raid1 btrfs defaults,nofail,noatime,nodiratime,compress=zstd 0 2 # <<< [openmediavault]  
29. Modify /mnt/nasrootbtrfs/@/boot/armbianEnv.txt.  In particular modify rootdev, rootfstype, and add 'extraargs'.  Old version:
verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=dabb3dbf-8631-4051-a032-c0b97eb285bd rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u  
New version:
verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=240bab7d-1b6c-48f4-898d-ba12abcecb3f rootfstype=btrfs usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u extraargs=rootflags=subvol=@  
30. Make a 'boot' symlink.  I'm not sure if this is necessary, but u-boot expects the boot files to be in the '/boot' directory on the root filesystem, but they are now in the root directory of the boot partition.  This symlink makes sure that if u-boot tries to access /boot/foo, it will actually access /foo.
# cd /mnt/nasrootbtrfs/@/boot # ln -s . boot  
31.  Unmount everything:
# umount /mnt/nasrootbtrfs/@/var/log # umount /mnt/nasrootbtrfs/@/home # umount /mnt/nasrootbtrfs/@/boot # umount /mnt/nasrootbtrfs/  
32. Power off helios64
33. Remove sd card
34. Start picocom on your laptop ('picocom -b 1500000 /dev/ttyUSB0')
35. Turn on helios 64 and look for startup.
 
TROUBLESHOOTING:
Of course this did not work on the first attempt for me.  After rebooting the helios64, it never successfully booted into Linux.  I didn't see any errors from u-boot.  To troubleshoot, I wrote the original helios64 debian buster image to sd card and booted the helios64 to that.  I mounted /dev/mmcblk1p1 to /mnt, and changed the 'verbosity' to 7 in armbianEnv.txt.  I eventually discovered that I had the UUID wrong in /boot/armbianEnv.txt.  Correcting that value fixed the issue, and the helios64 booted successfully from eMMC.
 
SETTING UP AUTOMATED SNAPSHOTS AND BACKUPS:
Enabling 'snapper' for automated root snapshots was very easy:
1. sudo apt install snapper
2. sudo snapper -c root create-config /
 
The debian snapper automatically take snapshots before and after apt upgrades.  However since /boot is a separate filesystem, this is not included in these snapshots.  As a workaround, I added an apt hook which rsyncs /boot to /.bootbackup before the snapshots are made.  Note that the 'snapper' hook is /etc/apt/apt.conf.d/80snapper, so I created /etc/apt/apt.conf.d/79-snapper-boot-backup:
# /etc/apt/apt.conf.d/79-snapper-boot-backup DPkg::Pre-Invoke { "if mountpoint -q /boot && [ -e /.bootbackup ] ; then rsync -a --delete /boot /.bootbackup || true ; fi"; }; DPkg::Post-Invoke { "if mountpoint -q /boot && [ -e /.bootbackup ] ; then rsync -a --delete /boot /.bootbackup || true ; fi"; };  
This takes care of automated snapshots.  I still want snapshots stored on another drive (or another system) for redundancy.  I'm using 'btrbk' to do this.  btrbk wants the btrfs top-level subvolume mounted somewhere.  To do so, I created the directory /mnt/btr_pool, and added the following line to /etc/fstab:
UUID=240bab7d-1b6c-48f4-898d-ba12abcecb3f /mnt/btr_pool/ btrfs defaults,noatime,compress=zstd,ssd,subvolid=5 0 0  
My spinning drive array on the helios64 is a btrfs filesystem, and I have it mounted on /srv/dev-disk-by-label-helios64_btrfs_raid1.  I created a '/srv/.../backups/helios64/btrfs/volumes' directory.  I then created the following three files:
 
/srv/dev-disk-by-label-helios64_btrfs_raid1/backups/helios64/btrfs/btrbk.conf:
timestamp_format long volume /mnt/btr_pool snapshot_dir btrbk snapshot_preserve 30d snapshot_preserve_min latest target_preserve 7d 8w 6m target_preserve_min latest target send-receive /srv/dev-disk-by-label-helios64_btrfs_raid1/backups/helios64/btrfs/volumes subvolume @ subvolume @home subvolume @var_log  
/srv/dev-disk-by-label-helios64_btrfs_raid1/backups/helios64/btrfs/rsync_boot.sh:
#!/bin/sh set -e -x mountpoint /boot [ -e /.bootbackup ] rsync -a --delete /boot /.bootbackup  
/srv/dev-disk-by-label-helios64_btrfs_raid1/backups/helios64/btrfs/run.sh
#!/bin/bash set -e -x CDIR=$( dirname ${BASH_SOURCE[0]} ) ${CDIR}/rsync_boot.sh btrbk -c ${CDIR}/btrbk.conf run  
I then added a daily cron job which runs the 'run.sh' script.
 
Well, that was a longer post than I had imagined.  I hope someone finds it helpful.

Keep in mind that after package upgrade you also should install new uboot release via armbian-config.

I will just add a bit more. 
 
We want to rewrite / make this from scratch with Ansible. Basically we seek Ansible expert or someone who wants to become one.  We have this know-how but we are simply too overloaded to move on. This is yet another job for common good! To make Armbian support better. To make Debian support better. To make Arch better, OpenWrt, ... To make every Linux distro out there running better on your board.
 
The person(s) should focus only on testing. Creating and maintaining scripts for automated testing and later, when our support hardware is out of beta testing, implement that as well. It's a continuous project and will not end tomorrow. Also you don't need to stay on it forever. Do what you can. Help us get going ...
 
We would like to automate:
 
- initial board setup (after you flash the image, automated 1st login, setup network, different local repository, ...)
- simple tasks such as upgrade, change to beta repository, downgrade to specific kernel, etc.
- run various of tasks which can be added without limits
- run various of benchmarks which can be added without limits
- run tasks in parallel
- make reporting in HTML, XML (common and per board)

Most of those ideas are covered in some basic form in our first try: https://github.com/armbian/autotests
 
More ideas:
https://github.com/SoInteractive/ansible-benchmark
 

The tag was always there but at a different configuration level so no need to change it manually ;-)
 
Nonetheless the ideas to explore for this issue (which I will unfortunately have no time for in foreseeable future) would be:
Disable HDMI support for rk3399 boards in u-boot again - something like this PR (may need adjustments)
It was already disabled once because of similar issues (which were supposed to be fixed with v2020.07) but I am leaning towards disabling it for all rk3399 boards again; Blacklist panfrost module, reboot and see if it helps - there was quite some development in panfrost between 5.4 and 5.8
This however does not apply to issues found in legacy; Try both of the above at the same time if none helps on its own; If you can spare some time - try testing the above scenarios.

Pull request mention HDMI specifically:https://github.com/armbian/build/pull/2302 
 
Although I not sure about what DWC3 driver limitation he is talking about. (HDMI+hub combo working fine for me on ROCKPro64 with legacy kernel.)

@0utc45t, try legacy image. if it still not working, make sure your cable has converter chip inside.
There are at least 2 standards regarding display signal in USB Type-C. one is DisplayPort Alternate Mode, which is the one supported on Helios64 (RK3399) and the other one is HDMI Alt mode.
If you have cable that use HDMI Alt mode, it won't work on Helios64.
 
@RussianNeuroMancer,
yes. on legacy, HDMI+Hub combo working fine. The problem with mainline driver, it does not support OTG. You have to define the port as "host" or "peripheral" in device tree.
That PR comment, before i knew https://github.com/armbian/build/pull/2299
HDMI+hub combo working fine in LK5.9 if you also enable rockchip-dwc3-0-host overlay.

Pull request mention HDMI specifically:https://github.com/armbian/build/pull/2302 
 
Although I not sure about what DWC3 driver limitation he is talking about. (HDMI+hub combo working fine for me on ROCKPro64 with legacy kernel.)

We are updating several kernel drivers with their best option - which is also a reason why Armbian is better then some generic Linux. Yes, it is used:
https://github.com/armbian/build/blob/master/lib/compilation-prepare.sh#L201-L213
 

I already update our fork to 2.14 and if you build kernel from sources, it will be v2.14. In case you want to change anything in the driver, send a PR. Either to upstream or our fork - just note about the changes since its not heavily monitored. Usually we just point to original source. I forget why we use a fork in this case. Not that important after all.

I the past few days I got several messages regarding this problem, even all corespondent knows that Armbian official policy only support images that are digitally signed. That is Armbian and its supported under those terms (make sure to read them before making more damages). Everything else you found floating on the internet you are using on your own risk. Why this topic? Since majority of R&D costs are covered from our private pockets (for official Armbian public share is between 0.2 and 0.4%),  most of your requests (for more of our private time/cash) can only ends in "f* off", "stop wasting our time", ... This is open source and "you", the one that need this and that function, full working and supported OS on every cheap garbage you purchase for a few bucks ... fork the code and maintain it! Armbian base maintenance (also source for TV boxes) currently costs us between 2.000 and 5.000 EUR per day and I have no idea how much people that fork this project adds that things also works (no idea how well) on TV boxes, that are similar to SBCs. If only 10% its already a lot! And what do they / we get back for that? Extreme constant demand and dissatisfaction since its absolutely not possible to fix all problems (for just 100 hours per day) and people doesn't (want to) understand that.
 
We - Armbian - doesn't want to do anything with our forks - focusing to single board computers represent an insane big project, which we have already have big troubles to keep up. This policy is present since ever and for several months we are trying at least to do something about. Many people were investing their precious time into the project "What to do with TV boxes" to make this clear, to find best relationship and perhaps also support important Armbian forks in some way. Project is again 99.9% covered from our private pockets.
 
If @balbes150 decided to stop supporting free of charge for you, for whatever reason, we have nothing to complain and I am sure we all fully support his decision but perhaps his Google translated words might scared you off. If he stop maintaining things, he is no longer responsible that boards breaks down. HW defects because of leaving off maintenance are extremely rare, but possible - I think he wanted to emphasize that. One doesn't need to add any evil code, hardware starts to break down when support is canceled, slowly but surely ... Besides, he is not to blame. Open source projects are done together - if you don't help him (and apparently you don't, with rare exceptions) and at least inspect and correct his work, why complaining and worrying about bad/evil code? Join development process and stop being cheap consumer who is complaining over the product he got for free.

Make sure to check his (and also our) code and also perhaps understand that he might need a full-time assistant(s) to roll things out at the present level. If not, why the fuck anyone complains? There is a fork button.
 
How to help improving things? https://www.armbian.com/get-involved/ The same way for TV Box Armbian fork.

I build today snapshot from oibaf for armhf too, but only for eoan: ppa:russianneuromancer/drivers
https://launchpad.net/~russianneuromancer/+archive/ubuntu/drivers/+packages?field.name_filter=&field.status_filter=published&field.series_filter=eoan
 

This issue is fixed since version 1.10.1+dfsg-4 and Ubuntu 20.10 already ship newer package (1.10.1+dfsg-7).
You can use TigerVNC 1.10.1+dfsg-7 on Ubuntu 20.04 as well, but this will require manual downloading of tigervnc packages here: https://launchpad.net/ubuntu/+source/tigervnc
 
Relevant bugreports:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932499
https://github.com/TigerVNC/tigervnc/issues/1023

New patches for mainline u-boot have been posted, so that espressobin should finally work now.
That gives us a recent version of u-boot, compared to that old and unmaintained marvell fork.
 
I opened a PR for OpenWRT to ship mainline u-boot/atf builds. Those also include distro boot:
openwrt/openwrt#3360
 
And now we need testers
openwrt/openwrt#3360 (comment)
 
While this is a PR for OpenWRT, I boot vanilla debian with it. In the end the distro shouldn't matter
 
Note:
* All builds are currently CPU_800_DDR_800 only for stability reasons
* There is no build for v5 with 2GiB RAM, does anyone have such a board? builds added in the posted v2 binaries
* The v5 1GiB build is 2CS, does anyone have 1GiB 1CS? builds added in the posted v2 binaries
 
And feedback is appreciated!

FYI, I found that this was due to a missing entry in debian-config-functions so I submitted a PR to add it (here) and this has now been merged so it should be available on the next update of armbian-config!

The new version 20.05.5 (20200522).
All images are build entirely on the ARM platform (rk3399 + NVMe). After fixing bugs, the process of building the first image (including downloading sources, building all packages, building the kernel, u-boot, and so on) took less than 50 minutes. 

If you are still interested in Type-C for mainline kernels. My patches at least explain what is missing in the present drivers and why this magic dr_mode = "host" is specified everywhere in the mainline dtbs

A bit of offtopic, but if anyone is interested Hardkernel is more open about RMA.

One of my NanoPC T4 also died a four months ago for no apparent reason, some symptoms was similar to description from Oleksii post. Initially it always printed long stack trace to serial console during rockchip_drm initialization, and then reboot on emmc initialization attempt. Later it stopped booting from emmc as if it's empty, but attempts to boot from microsd always lead to same outcome - boot loop. And finally it stopped even trying to boot from microsd with only red light.
 
FriendlyARM send replacement for this board, but making them doing so certainly wasn't easy - when all troubleshooting steps doesn't help, they decided to stop answering until I tried to place a new order via sales e-mail and asked them to put replacement board into this order.

@Igor @RussianNeuroMancer for the chronyd-bug with ubunutu focal you could take a look here
https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1878005
where they found a problem/solution:
* Chrony can't start on platorms that map gettimeofday to clock_gettime64() * This is due to syscall filtering being correct on some but generic enough to cover all areas. as a temporary solution they wrote:
 
So we will need to whitelist the clock_gettime64() system call in chronyd’s seccomp filter. I’ll send a patch upstream. Meanwhile, you can disable the seccomp filter by running (as root): # sed -i '/DAEMON_OPTS=/s/"-F -1"/"-F 0"/' /etc/default/chrony # systemctl restart chrony.service BTW: My NanoPi A64 with  armbian focal  kernel 5.6.12 is running
chronyd v3.5-6ubuntu6 normally:

System diagnosis information has been uploaded to http://ix.io/2mbU 

I don't need this board working now 100% and it is also impossible to do that in a short time. Even if we put all our resources into it. It is also expensive and slow to bring this support from where it is now, to perfectly working. Since we pay for everything and you for nothing, we proceed with our speed. Until then we will only rely on upstream fixes (like everyone else), which will ofc takes months to emerge: keep updating and once it will just start working ...
 
I have zero time to deal with this, nor is anyone dealing with this board to iron out those problems ... if you can't debug and fix some problem, forget it and use stock images which I assume might be better, but also not without bugs at this early stage. Usually it takes months to year that a board is production stable.
 
Temporally closing this thread since this board does not have end user support. If you are not a developer, you can only help this way: https://www.armbian.com/donate or doing something else that is in the project interest.
 
We haven't decide if we will pay the costs for dealing with you for this board which is on average around 20.000 EUR / year. You expect some real help or someone who has no clue about?
 
Edit: I also manage to kill the only board.

Fixed issues with networking.

It is not so obvious  I only consider the state in the mainline kernel as a reference (because I decided for myself to track changes since 5.* only). And I see that USB Type-C controller changes its state from "host" to "gadget" and almost immediately powers off during the boot. It should be correctly handled automatically by the driver on this board according to my understanding. And forcing to host mode is imho just a workaround for some issue in the current driver (or some other problems in device tree).

I guess he found it here: https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/codecs/es8316/EnableSeq.conf#L16

It was mentioned to me by email that the ethernet TX issue I describe here
plagues this board as well (my board is the LibreComputer Renegade).
 
It seems like the exact parameters might depend on each specific device, in which case the "best" solution would be some kind of "autoconfiguration" for the PBL, but that is in a future TODO. More about the issue andthe discussion here:
https://patchwork.kernel.org/patch/10880481/
 
Eventually this patch was merged for the Renegade upstream:
https://patchwork.kernel.org/patch/11017833/