Werner

I'd say depends. If you like the challenge of scripting this which for sure should be possible then do that. On the other hand though the easier setup is by following @xwiggen's advice, not lastly because WiFi dongles have become very cheap...

security through obscurity was never a good practice IMHO... Though I have to admit that I change my SSH ports too to avoid background noise spamming the logs

It is not important to bump dev to 5.8 since dev branch is usually not a part of any release. Btw @Igor is already working on a branch to make the bump happen: https://github.com/armbian/build/commits/sunx_megi_58

- Move RK3399 to Bugtracker since we have boards that are "supported" already (Orange Pi 4 for example). - We COULD merge some stuff but I wont do it because as it is right now it is divied by board family (for example: A20, H2+H3 are sunxi while H5/A64 and H6 are sunxi64). - Remove "board does not start" forums entirely since those issues could also be posted in the equivalent board family subforums within "Bug tracker"? -- As from SEO perspective could also be made read-only with the hint to write further issues into the forums described above - Merge common issues and peer to peer technical support?

Thanks for updating. Weird behavior is often caused by bad power supply and/or cables. It is also hard to get logs from a system that froze or broke since ramlog keeps the logs in memory and has no chance to write them to the sd card. Therefore those logs are often clean What you CAN do though is hooking up a serial console to the debug connector and let it run until it crashes and check the output. Also increase the verbosity in armbianEnv.txt. Check the documentation for that.

Not very good...But I dont wanna spoiler you

Won't help it is the cause I was thinking about. Still present in 5.7 which are current and dev on now. @Clément Peron Did some initial work on the dvfs stuff I think and it will take some more time until it gets upstreamed.

Try fixing the GPU clock like described here:https://armbian.atlassian.net/projects/AR/issues/AR-374?filter=allissues

Broken monitor/cable?

For the Amlogic S905(x) forums add S912 and S922 to it? I don't think there is a need to divite those into the other supported boards.

Maybe U-Boot is lacking USB support. Tried the compromise to leave U-Boot on the sdcard and put the rest on a stick? You can try to use "sata-nand-install" script to achieve that.

ii linux-dtb-next-sunxi 5.92 armhf Linux DTB, version 4.19.62-sunxi ii linux-image-next-sunxi 5.92 armhf Linux kernel, version 4.19.62-sunxi Your system is way outdated and therefore does not receive further support. Upgrade to a more recent current kernel/dtb package or legacy at least if available. Try a different power source and cable.

https://armbian.laet.pw/_extra/Armbian_20.08.0-trunk_Lamobo-r1_buster_current_5.7.11.img.xz No warranty. No support

I'll try to build an image for you. If it compiles I'll put the link here once its finished. May take a while. I recently cleaned up all caches.

If the board is not there https://www.armbian.com/download/ then there is no image since Armbian does not support it. Try https://duckduckgo.com/?q=Lamobo+R1+debian+buster&t=ffcm&ia=web Edit: Just checked. The board is EOS. Therefore there will be no images available. You have to build your own image but it will be unsupported if something does not work. Build tools are available here: https://github.com/armbian/build

M1 is built around the Allwiner A20 SoC which is 32bit or armhf to say. The Ubuntu server image for arm seems to be built for arm64. So no, won't work. Also I do not see this board in the list of supported SBCs: https://wiki.ubuntu.com/ARM/Server/Install

When choosing a WiFi dongle make sure it is built around a chip which driver is included: https://github.com/armbian/build/blob/master/lib/compilation-prepare.sh#L179-L507

I mostly did not know anything about Github either two years ago It is not that hard but sometimes it can really freak you out

Not yet but now. I predict it will freeze in one or two days...

Nanopi NEO3 sbc-bench v0.7.2 Installing needed tools. This may take some time... Done. Checking cpufreq OPP... Done. Executing tinymembench. This will take a long time... Done. Executing OpenSSL benchmark. This will take 3 minutes... Done. Executing 7-zip benchmark. This will take a long time... Done. Executing cpuminer. This will take 5 minutes... Done. Checking cpufreq OPP... Done. ATTENTION: Throttling might have occured. Check the log for details. Memory performance: memcpy: 1948.3 MB/s memset: 8083.2 MB/s Cpuminer total scores (5 minutes execution): 4.08,4.07,4.06,4.05,4.04,4.03,4.02,4.01,3.99,3.98 kH/s 7-zip total scores (3 consecutive runs): 3150,3054,3051 OpenSSL results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 125747.97k 378803.20k 745028.27k 1012273.83k 1130624.34k 1138742.61k aes-128-cbc 125746.60k 378807.36k 745014.19k 1012373.85k 1130438.66k 1138584.23k aes-192-cbc 120134.05k 338687.04k 610389.59k 781727.06k 851307.18k 854114.30k aes-192-cbc 120137.72k 338483.46k 610327.72k 781726.04k 851410.94k 855015.42k aes-256-cbc 116654.97k 312612.16k 529961.22k 654577.66k 702780.76k 705893.72k aes-256-cbc 116639.30k 312161.51k 530029.65k 653739.01k 702778.03k 705997.48k Full results uploaded to http://ix.io/2sIV. Please check the log for anomalies (e.g. swapping or throttling happenend) and otherwise share this URL. http://ix.io/2sIV

To be honest if the given explanations through the link are not enough you should keep considering PCIe broken for now and wait until somebody upstreams her work.

For longer pastes please use either an external paste provider like pastebin, hastebin, paste.debian.net or use the spoiler function to increase readability

In theory you were right, but unfortunately it is not. I have two OPi One side by side. One with the defect and one known to work. I swapped the sd cards and the sd card out of the defective board booted flawless on the known-to-work board while the known-to-work sd card did not boot in the defective board. After a dozen power cycles it came back once but I do not trust it anymore.

Hi, please use the spoiler tool to hide longer pastes to increase readability How did you setup the AP? Did you use armbian-config for that?

How did you make the custom patch? Did you use the CREATE_PATCHES flag?