JORGETECH

@Cesar Berci it got me interested enough that I ported changes to v5.10 with cleaner approach. Here you have commit: https://github.com/jernejsk/linux-1/commit/ad153ef6ee5be33531187f97d5fa0c07455dc795
NOTE: You have to enable tve node in DT you want. I did that in OPi PC.

Thanks to Werner, I have a stable desktop on my Orange Pi 3 running the Armbian_20.05.4_Orangepi3_focal_current_5.4.45_desktop.img.xz (stable release).  MOD can put this elsewhere if it belongs in tutorials and not bugs.
 
Here is how to step through his fix for anyone new to linux (like myself).
1. After flashing and setting root and user, the user will be logged into the graphical Xfce desktop environment (DE) and will freeze soon.
2. On the next reboot you can try to use one of the separate terminals instead of the DE.  This is done by holding CTRL+ALT and selecting F1-F6
3. Quickly log into root account and type the following "sudo systemctl set-default multi-user"  This will disable the DE next time you load.
4. The system may freeze as the DE is being loaded, so its best to reset and log into the bash shell with root again.
5. We have to setup a shell script that runs every boot, as the files that Werner overwrites get replaced every time. We will edit/etc/rc.local
6. Goto "cd /etc/ " and chose your favorite editor.  I used vim, so I type "vim rc.local" to start editing.
7.  Add the lines that Werner posted earlier to the rc.local file 
cd /sys/devices/platform/soc/1800000.gpu/devfreq/1800000.gpu/ echo userspace > governor echo 756000000 > max_freq echo 756000000 > min_freq 8. Save and exit to shell.
9. last step is to enable the DE again, type "systemctl set-default graphical"
10.  Reboot and enjoy a stable desktop.
 
It took me about a day to have this working, mainly because of me not understanding the the GPU clock values were getting reset and not knowing unix commands & file structure.  It reminded me as a kid messing with the autoexec.bat on a ms-dos machine.  I am hoping to use an SDR and make this into a HD Radio Decoder (already built the NRSC-5 & GUI) , have it stream to an android head unit in my car & control via VNC.
 

GPU, Display Engine and HDMI all have different clock sources. It could still be HDMI clock issue, just different...

I manually added this to the already existing patch (just under the display engine definition, be sure to modify the diff notation if you try it yourself):
+&gpu { + mali-supply = <&reg_dcdcc>; + status = "okay"; +}; + With this little modification in place, I compiled the kernel and u-boot packages again. Now I have the relevant entries that Werner has and glxinfo reports panfrost is in use. I'll test more after adjusting the devfreq parameters.
 
EDIT: If I'm not mistaken, LibreELEC already has a patch that does the same thing but the one in Armbian needs to be adjusted (until the code is mainlined, obviously).

Ubuntu changed the location of the mini.iso file for the minimal Ubuntu (Server?) installer in their file servers (since the 20.04 release), it's now located here:
 
http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/legacy-images/netboot/mini.iso
 
The docs should be changed since it could be confusing for new users/developers.

https://github.com/armbian/documentation/pull/70

Hm indeed. I think I found something.
sun50i-h6-orangepi-lite2.dts includes sun50i-h6.dtsi
 
while in sun50i-h6-orangepi-one-plus.dts includes sun50i-h6-orangepi.dtsi which THEN includes sun50i-h6.dtsi and that one contains gpu information
So maybe this step is missing in the lite2 dt

Do I need to convert it back to dts too, or do I leave the armbian kernel dts? Do the modifications come from other patches?

I examined @AndreBotelho's DTB and it's not really much different from the DTB I'm already using, so I don't think it would change anything. However, patches like this could help, I think I should wait first for the Armbian patches to be adapted for 5.6 kernel and then continue testing. Forget it, it's already been merged, but I still have my doubts over the posted DTB.

Beware that TX output of OPiLite2 is 3.3V while your Arduino RX expect 5V, so it is maybe the reason why you don't see any output ...
Better purchase a 3.3V compatible USB-TTL dongle.

Don't do that, it can burn your H5 UART, RS232 are using inverted level of +/- 9V to 12V !!!
Right ! Not only CP2102, but there are others, such CH340.
Seeing your footer, in the meantime, you can use your OPiZero since it has UART1 on header.

Ok, now I understand better how hardware is defined in DTS files. I realized the Orange Pi Lite 2 DTS is really barebones compared to the Orange Pi 3. I can wait for kernel 5.7 to test more.
 
The question I have is: How does it work in LibreELEC if the same DTS is used? (Is it only needed for X11 acceleration?)
 
EDIT: I answered my own question. The LibreELEC pull request for Orange Pi Lite 2 (which I merged on my local repository) adds the GPU and Display Engine entries in the DTS. So Armbian would need to merge that in the first place, @Igor can you take a look at the commits from this pull request (if you have the time of course)?, it has both the GPU and DE added to the DTS unlike Armbian's one. I would do it myself but I fear I would break the working patch since I have to learn more about git and diff. EDIT: I enabled the gpu myself but I found the system to be unstable after doing that, I will try to debug it with UART (SSH crashes too) and report back.
Thanks, I completely forgot about that Linux naming convention inside the kernel.
 
As always, thanks for the useful advice and answers.

Ok, now I understand better how hardware is defined in DTS files. I realized the Orange Pi Lite 2 DTS is really barebones compared to the Orange Pi 3. I can wait for kernel 5.7 to test more.
 
The question I have is: How does it work in LibreELEC if the same DTS is used? (Is it only needed for X11 acceleration?)
 
EDIT: I answered my own question. The LibreELEC pull request for Orange Pi Lite 2 (which I merged on my local repository) adds the GPU and Display Engine entries in the DTS. So Armbian would need to merge that in the first place, @Igor can you take a look at the commits from this pull request (if you have the time of course)?, it has both the GPU and DE added to the DTS unlike Armbian's one. I would do it myself but I fear I would break the working patch since I have to learn more about git and diff. EDIT: I enabled the gpu myself but I found the system to be unstable after doing that, I will try to debug it with UART (SSH crashes too) and report back.
Thanks, I completely forgot about that Linux naming convention inside the kernel.
 
As always, thanks for the useful advice and answers.

No, they are disabled because nobody took time to properly enable them in board DTS until now (it will be in 5.7).
No, sun4i-drm is for all Allwinner SoCs, it supports Display Engine 1.0, 2.0 and 3.0. It's just named by Linux tradition where it takes name of first (oldest) supported platform.

if you use wayland session, panfrost is used by default.
if you use Xorg, a config file is required, which is same as lima. please follow: https://gitlab.freedesktop.org/lima/web
and make sure your xorg >= 1.20
 
 

if you use ubuntu, don't build mesa your self, you can use https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers
if you insist to build your self, please also update libdrm and libglvnd. these two deps are also important.
 
 

I occasionally experience same issue with my HDMI monitor but not with TV. I suspect that HDMI PHY settings may not be entirely correct, but I couldn't find any problem with them yet.

Your first question:
Although without a heatsink H6 boards easily go up to 70°C (still 10° behind throttling threshold), If you either install a fan or underclock the CPU to around 1.4 GHz, you can go 24/7 assuming there is no power outage or SW issue.
 
Second:
As you have already had a somehow similar server, you might know some issues that might happen, for example if you use microsdcard as your storage device, you won't get a super reliable server. (but I think using emmc might solve the problem)
Another thing I noticed is that when I installed pihole, the lighttpd stopped working after sometime randomly (it only hurt the web ui, the dns service was still running) , and the problem didn't go when I replaced it with apache, even after I completely removed FTL from pihole, and installed WP for other stuff. This is somehow strange because for example this had never occurred to my BLYNK server or cockpit on my OPi lite 2 board.
 
Third:
If you mean the OPi3 board, I'm not sure about its USB hub status, but I have OPi Lite 2 and the USB 3 works just fine. I haven't tested the speed yet, and I don't know whether it is behaving just like USB 2 or is in SS mode but I assume it is running at SS mode, because the output of lsusb command recognizes it as USB 3.
 
Summary:
If you install proper heatsink and cooling fan you can run the server 24/7 as I have had an uptime of around three weeks with OPi lite 2, and I haven't experienced any serious issues, and issues I said above can differ case to case. I think the board can be a suitable replacement/upgrade over OPi zero