djjerdog

I manged to get the USB OTG headers working on the NEO3 by modifying the NanoPi R2S DTB that it is currently using.
 
2 changes were needed:
- Replaced all usb2 references to usb0
- Changed dr_mode for usb@ff580000 from otg to peripheral
 
Modified DTB file attached if anyone else wants to give this a try or has a need for OTG on the NEO3
 
 
rk3328-nanopi-neo3-rev00.dtb

/usr/bin/brcm_patchram_plus/rk3399 hogs 100% CPU until rk3399-bluetooth.service is stopped and disabled.
 
The NanoPi Neo3 does not have bluetooth.
 
 

It was a bug. 
 
apt update and apt upgrade will fix it.

It works fine on Nanopineo2black image since yesterday. (tested)

The reason for discrepancy is here. Neo2 uses different config / DT.

Perhaps try to disable this:
https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization#L281-L318
and if that helps, RFC to force fsck before changing the file.

I finally managed to get the official buster desktop image for the nanopi-m4 fully working on the version 2 of this board too.
 
Basically, I extracted the working bootloader from the Armbian_5.99.191102_Rockpi-4b_Debian_buster_dev_5.3.0 image (which boots, but doesn't works well on the nanopi-m4 v2) and I burnt it to the https://dl.armbian.com/nanopim4/Debian_buster_default_desktop.7z image.
 
This morning I did some initial tests and it seems that everything is working well.
 
I have prepared a patched image you can try. At the moment, I've tested it only with an SD card, but I guess It'll work on the emmc too.
Download it from https://drive.google.com/open?id=1LaJIywiZnZUkLDZ9HkWrRtc0PyfiYGOL
 
You can also apply the patch by yourself:
 
1) download buster desktop image for nanoPi M4 (version 1) from Armbian's web site https://dl.armbian.com/nanopim4/Debian_buster_default_desktop.7z
2) extract and burn it to an SD card
3) apply the patch I have shared at the link above using the following command, changing sdX with the correct device:
sudo dd if=8M_after64ibs_uboot_working_rockpi4image_on_nanopim4v2.dd of=/dev/sdX seek=64  
Let me know if it works for you too.
 

We are working on it. Thanks for your support.

As mentioned in this thread and in another one, use RockPi image, it should boot ...
Then, after initial setup, root password and user creation, add this line "fdtfile=rockchip/rk3399-nanopi-m4.dtb" in /boot/armbianEnv.txt to get proper hardware setting.

Thanks for the info. I switched to Docker and the compiler is running now.

I can confirm the bug.
Using 20+ OrangePi Zero Plus with the extension board usb ports I noticed the same strange content of /boot/armbianEnv.txt as Magnet  described.
The file system seems to be fine, except this file. 
Since my systems use the USB from the extension board, once the port is not present, my device doesn't work.
My workaround is based on DoubleHP. I added a simple service that checks the content of the armbianEnv.txt file and react accordingly to the result. Her are the three files.
It works well on my systems, but please feel free to criticise it an point out any possible errors I made.
 
/root/bootenv_check/bootenv_check.service
[Unit] Description=Checking the validity of /boot/armbianEnv.txt file. After=sysinit.target [Service] Type=oneshot User=root ExecStart=/bin/bash /root/bootenv_check/bootenv_check.sh RemainAfterExit=yes [Install] WantedBy=basic.target  
/root/bootenv_check/bootenv_check.sh
#!/bin/bash file=/boot/armbianEnv.txt overlays="overlays=usbhost0 usbhost1 usbhost2 usbhost3" content="verbosity=1 console=serial overlay_prefix=sun50i-h5 "$overlays" rootdev=UUID=d59ef23a-f2e0-418c-85e9-e21611283218 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u" cat "$file" | grep -x -F "$overlays" >/dev/null && { #file is good. echo "$file seems to be valid (includes '$overlays')" } || { # File is bad echo -e "$file content is invalid: \n----" cat "$file" echo -e "----" # Fallback on the predefined content ... echo -e "$content" > "$file" echo "$file overwritten with default content" echo "REBOOT NOW" reboot }  
 
/root/bootenv_check/install_service.sh
 
#!/bin/bash #echo "The script you are running has basename `basename "$0"`, dirname `dirname "$0"`" echo "Installing bootenv_check.service in the system..." file="bootenv_check.service" target=`dirname "$(readlink -f "$0")"`"/"$file echo "Service file: $target" ln -s -T -v "$target" /etc/systemd/system/"$file" systemctl enable $file echo "... done"  

Yes, I know. Waiting for hardware to arrive ... it seems it was sent to a wrong destination