laibsch

... straightforward and smooth.
 

https://github.com/armbian/build/pull/8517 appears to fix my SFP problems.
 

Thanks @laibsch and @royk.
 
For now, we’ve managed to get things working by running the latest vendor kernel, but using panel-simple.c from version 6.1.43.
This workaround isn’t ideal, and we’ll try to investigate the root cause once we have more time.
 
As for the log message "Expected bpc in {6,8} but got: 0", it doesn’t appear when using 6.1.43, even though the relevant source code is identical in that part.

There are two ways to achieve hw acceleration: backported panthor or mali blobs.
Depending on your usecase latter might be necessary. You may find this interesting: https://jellyfin.org/docs/general/post-install/transcoding/hardware-acceleration/rockchip/#configure-on-linux-host
Don't forget to disable panthor overlay in /boot/armbianEnv.txt if you decide to go this route.

Revert to 6.15. The 6.16 package is useful for A523 only atm.
 
Don't use bleeding edge and complain about things breaking the same time.
To answer on your level: Either help fixing things or fuck off and move along.

This remembers me a recent set of changes to the DWC3 driver for RK3399 to fix exactly these kind of issues exposed here, including the single-orientation problem, plus some more issues with the displayport over usb type-c functionality.
 
The PR had a lot of comments but finally it got merged because both the author and me tested the whole apparatus and it proved to improve significantly the situation on rk3399: https://github.com/armbian/build/pull/8271

Patches should address some issues in the dwc3 driver in general, and I see from the device tree that rk356x uses the snps,dwc3 compatibility string, so probably also rk356x benefits from them as well. It would although require some device tree tinkering: I tested on Orange PI4 LTS board and the device tree fixes are within this hunk; rk356x-based devices can probably share several declarations but that depends upon the rk356x capabilities. I would start from changing dr_mode to otg and removing regulator-always-on; property from the vbus supply.

@twwn
 
Add to rk3566-radxa-zero-3.dtsi -->  snps,usb2-lpm-disable;
https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.12/dt/rk3566-radxa-zero-3.dtsi#L495
 
&usb_host0_xhci { dr_mode = "peripheral"; + snps,usb2-lpm-disable; status = "okay"; };  
See if it makes a difference.
 
Information:
https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/dwc3.txt

Just wanted to close this off after a two-week test.  With the fan, it did not shutdown at all.  Pretty much the issue is overheating.  Thanks for all the help!

@laibsch It seems that if you set the pixel clock or refresh rate too high that you can shorten its lifespan. But when you use extreme values and the display doesn't have any protection in rare cases you can even damage it.
 
A bigger chance is driver instability or a distorted display.

The helios4 is on its way to @laibsch. It is not available anymore...

It works like a charm. Thanks so much!

Hello @swthpk32
 
The Radxa Rock 5T in Armbian is maintained by @meco, maybe he will have something to say. 
 
I don't have the board, so I will only be of limited help.  Have you tried some of the commands given in the thread you linked and what was the result?  Can you confirm that your modem shows up for a second and then disappears?  Can you compile your own image with a vendor kernel?
 
nmcli -m 0 sudo dmesg | grep usb  

I used the Debian 12 uefi desktop image with @djzort‘s instructions and it works great! I’m convinced this is the best setup for the pbpro, at least for me. 

Thanks for the quick answer. I have ordered a USB serial adapter and should receive it next week. I'll update.

Just posting my experiences getting armbian going on pinebook pro. I had a pinebook pro on a shelf for a while, picked it up and ran "apt-get update" after which booting the system broke. So without anything important on there i figured i would reinstall.
 
Tow Boot
 
I had already installed an older version of Tow Boot, but i updated it to 2023.07-007 
 
This is a simple process. Write out the spi.installer.img to an sd card (i used dd). Insert the sd card in to the slot on the side of the pinebook. Start the system. Follow the prompts. Shut down the system. Remove the sd card. Power on the system and hit "Esc" to see the Tow Boot menus and verify the version has been updated in the "Firmware Console" by typing "version"
 
A major change appears to be that Tow Boot has inherited a minimum viable EFI interface from U-Boot. This allows generic efi arm images to boot, but because the efi configuration is stored in the efi partition rather than spi flash, tools like efibootmgr don't work. Read more here in github
 
(I don't think its worth trying to run without Tow Boot installed on the spi, despite the limited efi)
 
Install Armbian
 
I downloaded the Cinnamon Debian version listed on the Pinebook Pro page - the exact file was Armbian_25.2.1_Uefi-arm64_bookworm_current_6.12.13_cinnamon-backported-mesa_desktop.img.xz
 
I then unxz'd that file and dd the image to the sd card.
 
Insert the sd card in to the pinebook and power on. Armbian boots!
 
Install works as normal, but you will notice that efibootmgr commands are failing in the install script although they are non fatal at this stage. This is due to the Tow Boot efi limitations mentioned above.
 
Unfortunately, Armbian will install the grub efi binary as /EFI/Armbian/grubaa64.efi and failing to add a boot entry, the system will fail to boot.
 
You have two options.

The first is to copy /EFI/Armbian/grubaa64.efi to default location /EFI/BOOT/BOOTAA64.EFI - this is also perhaps the safest in the short term.
(note that on the installer sd card the file is located at /EFI/BOOT/BOOTAA64.EFI). You may need to manually mount the new EFI partition on the mmc and copy the file - do this before rebooting the system so the system remains bootable. If you don't there is no need to panic, adding a boot entry to Tow Boot's efi is very simple from its menus as i will now describe...
 
The second is to add a boot entry in the Tow Boot menus.
 
Contrary to the github issue linked above, it seems that in Tow Boot the "efidebug" command has been replaced with a more convenient set of commands to manage boot options.
 
Power on your pinebook pro, press "Esc" to see the Tow Boot menu and go in to "Firmware Console". Type "eficonfig" and use the convenient menu to add a new boot entry - not that the tow boot console has tab completion which is very convenient. In "eficonfig" hit enter on "Add Boot Option", set "Description" to "Armbian", hit enter on "File" then "Select File" then "mmc 0:1" and find the Armbian/grubaa64.efi file. Then "Save" (initrd and optional data left empty). Then "Change Boot Order" and move the new Armbian entry to the top with -/+ keys then Save. Exit "eficonfig" and continue with a normal boot by typing "bootefi bootmgr"
 
I suggest do both, and once the system is booting from the new boot entry you can remove the BOOTAA64.EFI file as good hygiene
 
I also observed that the Tow Boot menu does freeze up occasionally and the only solution is to press the power button. Also you do seem to need to press keys slowly.
 
Minor issue at log in
 
I observed that for a brief period the keyboard doesn't work at the log in prompt. 
 
The speakers give their normal tick sound and the cursor stops flashing - which presents like the system has frozen. I found that pressing the power button causes the system to gracefully shut down - so the system hasn't locked up. 
 
Be patient and a moment or two later, the cursor starts flashing again and the keyboard works. I dont know what is causing this behavior but perhaps someone else is interested to dive in to it.
 
Apt update and beyond
 
With the system booted and logged in, i ran updates and rebooted. Things continued to work properly
 

Ok, I'm going to summarize for posterity.
 
One can try ssh (which is enabled by default) with root/1234 (default), or the Debug TTY.  This does exist on the NanoPi R6S between the USB-C Power and HDMI port.  There are no headers soldered on, so that has to be done first with headers that can be purchased at one of the following URLs.
 
https://www.adafruit.com/product/3009
https://www.amazon.com/dp/B07PKKY8BX
 
 
Once the headers are one, you can connect to this port with a USB to UART device (preferably with a chip such as the CH340C, CP2104, FT232R) connected from another Windows, Linux or Mac computer.  I suspect this device will work.
 
https://www.amazon.com/gp/product/B07BBPX8B8
 
 
Debug TTY instructions are located here:
https://www.youtube.com/watch?v=UpVMO7gbnYM&t=226s
 
Thanks!

Absolutely, and I believe that @tabrisnet could be a great addition to the team of supporters.  In case he wants to do that.  He certainly seems to have a good skill set and required curiosity.

Of course you are free to try Armbian images, but you should know that the Orange PI 3b is not an Armbian supported board.  It is community support status and there is no maintainer who has volunteered to maintain it.  I just want you to understand and set your expectations appropriately for what an Armbian build will provide you.

@laibsch It actually worked, ty for help :))

Unfortunately I was not able to work on this topic appropriately and thus could not provide any helpful information.
But in the meantime, others have done a lot of work on this topic. Thank you @uablrek for the link.
So I tried and built a new image (from main branch) after https://github.com/armbian/build/pull/8449 had been merged. I can confirm that the Rock 4SE now boots with this version.
 
Thanks to everyone involved for the solution!

I ordered a NVMe HAT and the SSD works fine now. 
 
Thank you. 
 
Regards
 

Thank you for reporting back.  I am happy to hear you were able to find another way to solve the underlying issue without needing the v4l2loopback-dkms package anymore.
 
I see you already have backports enabled but probably with low priority (as you should) by default.   You can check "man apt" for information how to install that specific version (or use aptitude like I do).  That being said, "sudo apt install v4l2loopback-dkms/bookworm-backports" should probably get you the version you need and hopefully it would install fine.

As far as I understand the terminology, "standard support" means we have someone in the core team who has access to the device and regularly runs boot tests on the actual hardware and is willing to attempt to fix issues that are found (best effort, not a guarantee). It does not mean all hardware features of the board are working.
 
Source

Hello! Asus Tinkerboard is still perfectly supported by Armbian.
Best setup is the current LTS kernel 6.12, you can take an image from the official download page: https://www.armbian.com/tinkerboard/
 
enjoy!
 

Thank you @laibsch I unfortunately don't understand @Werner's response, but yours is very helpful, thank you very much!  I will look at trying to add that to my .bashrc or .zshrc I suppose! cheers