VyacheslavS

Hear is a lengthy reply I put on the Frigate NVR github for someone asking about hardware decoding for Frigate NVR. I would be interested if I am doing anything wrong here or I have missed a step.
 
TL;DR It does not work reliably for me  ATM but this is the closest to working I have seen so far. Work is ongoing in linux kernel and FFmpeg, it may work reliably sometime in the future. When the kernel drivers are moved out of staging and the interface to them is stable I expect to see a pull request on the main FFmpeg git. This is a long reply with information to test because I am giving up at this point and moving to a different platform. I would be interested if you find a solution though, or that I have missed something - hence the detailed reply.
For testing you can try this fork of ffmpeg https://github.com/jernejsk/FFmpeg It has v4l2-request and libdrm stateless VPU decoding built in using hantro and rockchip_vdec/rkvdec.
use kernel 5.14.9, armbian is a convenient way to change kernels - sudo armbian-config -> system -> Other kernels.  FFmpeg from the above github has private headers for kernel interfaces and they are updated about a month after each release. You must install the correct userspace kernel headers, I just get the kernel source from https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.14.9.tar.xz and then do `make -j6 headers_install INSTALL_HDR_PATH=/usr`
Do not use amrbian-config to install kernel headers - it installs the wrong version.
Then install FFmpeg dependencies:
`sudo apt install libudev-dev libfreetype-dev libmp3lame-dev libvorbis-dev libwebp-dev libx264-dev libx265-dev libssl-dev libdrm2 libdrm-dev pkg-config libfdk-aac-dev libopenjp2-7-dev`
Run configure, this is a minimal set of options, frigate includes many more though, I removed many of them to build faster and save memory (I actually think there are a lot of redundant ffmpeg components in frigates default build files, some X11 frame grabber stuff and codecs nobody uses anymore, but thats for a separate discussion):
``` ./configure \ --enable-libdrm \ --enable-v4l2-request \ --enable-libudev \ --disable-debug \ --disable-doc \ --disable-ffplay \ --enable-shared \ --enable-libfreetype \ --enable-gpl \ --enable-libmp3lame \ --enable-libvorbis \ --enable-libwebp \ --enable-libx265 \ --enable-libx264 \ --enable-nonfree \ --enable-openssl \ --enable-libfdk_aac \ --enable-postproc \ --extra-libs=-ldl \ --prefix="${PREFIX}" \ --enable-libopenjpeg \ --extra-libs=-lpthread \ --enable-neon ```
Then `make -j6`
I dont know if this next bit is correct, but it works for me, I dont want to do `make install` just run the ffmpeg tests from the build directory, to run tests you must run `sudo ldconfig $PWD $PWD/lib*` first otherwise linker will not find libraries.
If you want to try a different kernel version run `make distclean` in FFmpeg and run ./configure again. If FFmpeg fails to build it will be because private headers do not match kernel headers. errors like V4L... undefined etc
Then you can do some tests and see if you get valid output, for example, this decodes 15s from one of my cams:
`./ffmpeg -benchmark -loglevel debug -hwaccel drm  -i rtsp://192.168.50.144:8554/unicast  -t 15 -pix_fmt yuv420p -f rawvideo out.yuv`
Checks to make during and after decoding: 
Observe CPU usage, on my system rk3399 with 1.5Ghz little core and 2Ghz big core overclock I get between 17 and 25% cpu on one core, it varies if it runs on a53 little core or a72 big core. It should be better than that, I think its the way that the data is copied around in memory. Gstreamer or mpv attempt to do zero copy decoding so its more efficient. With software decoding CPU use is about 70% of one core. RK3328 does not have the two a72  cores and four a53 cores that RK3399 has, just four a53 cores so rk3328 about half as powerful as RK3399 as the a72 cores are about twice as powerful as the a53 cores.
You should see in the debug output for ffmpeg where it tries each of the /dev/video interfaces to find the correct codec for decoding. Be warned that ffmpeg will sometimes just fall back to software decode, if that happens you will see much higher CPU usage and often ffmpeg will spawn a number of threads to use all cores in your system. Your user should be a member of the "video" group in /etc/group to access without sudo. Log snippet of that section below:
```[h264 @ 0xaaab06cd9070] Format drm_prime chosen by get_format(). [h264 @ 0xaaab06cd9070] Format drm_prime requires hwaccel initialisation. [h264 @ 0xaaab06cd9070] ff_v4l2_request_init: avctx=0xaaab06cd9070 hw_device_ctx=0xaaab06c549a0 hw_frames_ctx=(nil) [h264 @ 0xaaab06cd9070] v4l2_request_probe_media_device: avctx=0xaaab06cd9070 ctx=0xffff8804df20 path=/dev/media1 driver=hantro-vpu [h264 @ 0xaaab06cd9070] v4l2_request_probe_video_device: avctx=0xaaab06cd9070 ctx=0xffff8804df20 path=/dev/video1 capabilities=69222400 [h264 @ 0xaaab06cd9070] v4l2_request_try_format: pixelformat 875967059 not supported for type 10 [h264 @ 0xaaab06cd9070] v4l2_request_probe_video_device: try output format failed [h264 @ 0xaaab06cd9070] v4l2_request_probe_video_device: avctx=0xaaab06cd9070 ctx=0xffff8804df20 path=/dev/video2 capabilities=69222400 [h264 @ 0xaaab06cd9070] v4l2_request_try_format: pixelformat 875967059 not supported for type 10 [h264 @ 0xaaab06cd9070] v4l2_request_probe_video_device: try output format failed [h264 @ 0xaaab06cd9070] v4l2_request_probe_media_device: avctx=0xaaab06cd9070 ctx=0xffff8804df20 path=/dev/media0 driver=rkvdec [h264 @ 0xaaab06cd9070] v4l2_request_probe_video_device: avctx=0xaaab06cd9070 ctx=0xffff8804df20 path=/dev/video0 capabilities=69222400 [h264 @ 0xaaab06cd9070] v4l2_request_init_context: pixelformat=842094158 width=1600 height=912 bytesperline=1600 sizeimage=2918400 num_planes=1 [h264 @ 0xaaab06cd9070] ff_v4l2_request_frame_params: avctx=0xaaab06cd9070 ctx=0xffff8804df20 hw_frames_ctx=0xffff8804faa0 hwfc=0xffff8804e530 pool=0xffff8805e910 width=1600 height=912 initial_pool_size=3 ```
Check that the output file contains valid video data, try playing it using vlc:
`vlc  --rawvid-fps 10 --rawvid-width 1600 --rawvid-height 900 --rawvid-chroma I420 out.yuv`
adjust the command to what height/width/fps your cameras record in.
If all this is working then try doing longer decodes in parallel, eg is you have 3 cams run the ffmpeg command for each of them in a separate window and increase the time. What happens to me is that at some point ffmpeg will start reporting "resource not available/busy" or similar, rebooting will make it work for a while again. 
You can check what codecs are supported by each of the interfaces /dev/video[012] by `v4l2-ctl --all -d0` change d0 to d1 d2 etc to view the other decoders/encoders
You can monitor the state of kernel development https://patchwork.kernel.org/project/linux-rockchip/list/  Most of the work on this is being done by Andrzej Pietrasiewicz. My suggestion is monitor  both the ffmpeg github and kernel commits/patches, find out when they rebase ffmpeg. Pull that version and install the current kernel for it plus headers and retest.
I have all the frigate docker files already created. I basically created a new set of  dockerfiles with an arch of aarch64rockchip and added those to Makefile. I'll upload them to my github at some point, I see little point to a pull request since rockchip is a niche platform with not many users in home assistant or frigate, and it does not currently work for me reliably anyway.
I have been trying to get this working for some time now, at kernel 5.4.* there were a bunch of kernel patches you had to apply. Nothing worked for me then. Often FFmpeg complained about the pixel format. There were some people on Armbian forums who claimed to have it working, but I had my doubts, maybe it was wishful thinking and ffmpeg was really using software decode. Most of the effort around this is for video playback so people can play 1080p and 2/4k videos on desktop and  kodi. There is little information about straight decoding to a pipe like frigate. So in research ignore stuff to do with patched libva etc.
For now I am using an old ~2013 i5-4670 four core/thread Haswell with Nvidia GT640 GPU for Frigate and Home Assistant. For three cams at 1600*900 10fps Frigate uses 6% CPU as reported by Home Assistant supervisor. It is very stable. With that in mind and wanting to use a more power efficient system I caved and ordered a Nvidia Jetson 4GB developer kit yesterday. I have confidence I can build Frigate docker containers for that system and it has a similar hardware decoder as their GPUs, I can also try out using CUDA filters and scaling to reduce CPU load for Frigate detector. A start would be to copy the amd64nvidia dockerfiles and create aarch64nvidia arch and modify from there it should be mostly the same.
 
 

they are back in stock now from what i see , i just ordered one last week
 
https://www.aliexpress.com/item/4000575054675.html?spm=2114.12010612.8148356.1.30b67fddNzcI4W

Thnx Werner little cryptic message
 
Yah already updated topic titel i made some fixes
 
HDMI Uboot support works it was a dts change in the kernel dts , &cdn_dp and hantro are not good friends with hdmi yet
so
from SD
 SD (duh) ,USB3, USB-C works so pi 4b users can have some more options as the sd and mmc ,emmc and nvme not tested yet.
From SPI
SD ,USB3 , somehow fusb302 keeps his f up to still be fuzzy so no USB-C yet Uboot gives it no power and mmc and nvme not tested yet .
 
HavE Fun
 
Ps you can now change pi to his own
 
elif [[ $BOARD == orangepi4 ]]; then
    BOOT_USE_BLOBS=yes
    BOOT_SUPPORT_SPI=yes
    BOOT_SOC=rk3399
    DDR_BLOB='rk33/rk3399_ddr_933MHz_v1.24.bin' # Orange Pi 4 does it has 4gb standard and is cheaper and b has also a ai 
    MINILOADER_BLOB='rk33/rk3399_miniloader_v1.19.bin'
    BL31_BLOB='rk33/rk3399_bl31_v1.30.elf'
 
or 
elif [[ $BOARD == orangepi4 ]]; then
    BOOT_USE_MAINLINE_ATF=yes
    BOOT_SUPPORT_SPI=yes
    BOOT_SOC=rk3399
    ATFPATCHDIR='atf-rk3399'
 
if you apply the changes
 
 
 
 
 
 
 
kernel-rockchip64-dev.patch linux-dtb-dev-rockchip64_21.02.0-trunk_arm64.deb linux-u-boot-dev-orangepi4_21.02.0-trunk_arm64.deb orangepi-4-rk3399_defconfig rk3399-orangepi-4-kernel.dts rk3399-orangepi-4-u-boot.dtsi rk3399-orangepi-4-uboot.dts sd-usbc-dmesg.txt spi-uboot-atf-log.txt u-boot-rockchip64-dev.patch

After Seeing all that spi nmve boot hype for the other boards and some time left i took the effort to level up the Orange Pi boards because they are the same as the rest it has a rk3399.
 
The Uboot was a mess so i matched it with the kerenel dts a lot and corrected some issues.
Dts debug is not the friendliest debug it compiles or not
 
And after some trial and error (a lot ) and finding a spi nor flash wich is supported (or you add one of your own) it costs a esp8266 has 4mb spi flash or a old printer who had a 4mb and 8mb
i got a boot from spi so . and with reading the armbian forum i saw 150balbes talked about usb boot and didnt know if usb3 works well after adding some tcphy usb was seen by uboot  .
 
so SPI > USB3 boot works and take note USB3 not USBC (fusb30x) yet
 
so next attempt was emmc so ordered some emmc chips , and because there are a lot i made the mistake to order 4.5 instead at least 5.0 so emmc is not checked but should work nothing realy changed there maybey the env in uboot option
 
and you saw also the ? with nvme yeah that is in the mailbox from ali but should also work but is not tested .
 
And even take the kernel dts and changed that to match the other dts in alphabetic order and added USBC so kernel sees the usbc port and change to what is connected as you can see in the kernel logs .only it broke a little the hdmi uboot option why i think it was late and forgot a dts option but i got both the dtb so only have to check what option i forogot to combine those 2 usbc and hdmi .
 
And sure there will be mistakes by me but at least the orangepi4 has is dts updated and more boot options as before and even more as other boards.
 
i attach the armbian patches and log files for who is interested .
 
have fun with it
 
ow ps
you have to change the
 
\build\config\boards\orangepi4.conf
and add
BOOT_FDT_FILE="rockchip/rk3399-orangepi-4.dtb"
 
and in
\build\config\sources\families\rk3399.conf
add
BOOT_SUPPORT_SPI=yes
 

 
 
 
 
hdmi.dtb hdmi.dts kernel-rockchip64-dev.patch orangepi-4-rk3399_defconfig rk3399-orangepi-4-kernel.dts rk3399-orangepi-4-uboot.dts sd-boot-log.txt sd-dmesg.txt spi-sd-sd-bootlog.txt spi-sd-sd-dmesg.txt spi-sd-sd-dmesg-usbc.txt spi-usb3-hdmi-bootlog.txt spi-usb3-hdmi-dmesg-console.txt spi-usb3-hdmi-dmesg-desktop.txt u-boot-rockchip64-dev.patch usbc.dtb usbc.dts

IT'S FINALLY HERE...

THE OFFICIAL ROCKCHIP-LEGACY MULTIMEDIA INTEGRATION
 
After two years of using a separate script to enable the multimedia features in RK3399 Legacy Kernel, the whole framework has been incorporated to the official Armbian packaging system. The choice distro for this integration is Debian Buster (see FAQ at the end of this post about the reasons).
 
I. Installation
Download a Armbian Buster Legacy Desktop image for your board, and install it with the standard Armbian method. Install the complete multimedia solution with sudo apt update && sudo apt upgrade sudo apt install media-buster-legacy-rk3399 --install-recommends The switch "--install-recommends" will add the whole Kodi binary addons collection (retro-gaming cores, music visualizations, screensavers, additional media decoders/encoders, vfs, etc.), plus the GLES-to-OpenGL wrapper "gl4es".
 
II. Features
Accelerated GLES/EGL X desktop: No action needed. Accelerated Chromium, with WebGL and video display acceleration: No action needed Desktop video player capable of smooth 4K HEVC-HDR: Use the "Rockchip Gst Player" from the Multimedia menu, or choose it with right-click on the media file. Command-line 4K playing is also possible with "gst-play-1.0 --videosink=kmssink". RKMPP-accelerated MPV: Use normally for standard operation (windowed with mouse-operated GUI). For fullscreen, keyboard-operated mode, use the command line switch "--gpu-context=drm" (this will allow you to play smooth 4K).
        - See instructions below, in the next post, for playing YouTube videos up to 4K with this MPV.
ISP Camera with real-time h.264/1080p HW encoding: Using the Gstreamer Plugin. Check this wiki for instructions on how to use it. Most of it applies to Armbian, except for the selection of ov5647/imx219 camera, which must be done using DT overlays. OpenCL 1.2 support: It will be fully functional, no further action needed. You can download some tests and examples from this link. Kodi 18.9 Leia with full RKMPP+GBM acceleration, 4K-HDR capable: You can start it from LightDM menu as your user account: 


Alternatively, you can also run it as a system service with these command lines: sudo systemctl disable lightdm sudo systemctl enable kodi-gbm sudo reboot Full collection of Kodi binary add-ons: Includes retrogaming cores, media encoders and decoders, PVR, screensavers, vfs and audio visualizations. They are all installed with the package "kodi-addons-full", but are disabled by default. They need to be enabled individually within the Kodi GUI. OpenGL 2.1 support through the gl4es wrapper: It is installed with the package "gl4es", with no further action needed.  
III. Sources
This is the list of the sources used for the packages:
 
IV. FAQ
¿Why did you use Debian Buster as a base for this implementation?
It was the most appropriate for several reasons. Upstream Rockchip-Linux developers use Debian buster, so the software could be ported with less modifications than if we chose a different distro. Besides, it is a completely stable distro, unlike Bullseye, which is a moving target as of today. It also has Chromium as a package, unlike Focal that uses snap instead. For last, it has a good backports repo, with several libs that would otherwise need to be compiled and maintained if we chose, for example, Focal.
  ¿Why Legacy instead of Mainline?
This is an implementation based on the vendor's BSP kernel. It has been tested and is reliable, which many people will prefer rather than having a bleeding-edge, less stable implementation. In addition to that, Mainline upstream multimedia support is still a WIP, and lacks many features that are only present on Legacy kernels.
  ¿Will you add new features to this implementation?
No, this implementation will only receive bug fixes if necessary. From now on, all multimedia work will be focused on Mainline and recent distros (like Focal or Bullseye). All new features will go there.

New release in the repos:
Fixed Chromium showing images in indexed color, and other limitations. Fixed OpenCL broken in last update Improved X performance under glamor (by 100%, in gtkperf tests) Fixed rkcamsrc plugin for using the ISP MIPI-CSI camera (ov5647 still needs some kernel work for rk3399). Added the Rockchip RGA library (also enabled in the kernel).

I also bought the same one, about 15 Euros.  I configured the script and now it starts to rotate from +35, the rotation speed is floating. The maximum spin speed starts at +60 . This cooler is really quiet and worth it money.

I have seen many tutorials about connecting real time clock hardware on Orange Pi and Raspberry Pi.
What i didn't like was removing of fake-hwclock service, because I want that RTC works when it is connected, and fake-hwclock when RTC is not connected.
Therefore, I changed /sbin/fake-hwclock script to work in this way.
 
So, here is how to do this, tested on OrangePi+2E, Armbian Ubuntu legacy kernel:
Purchase cheap DS3231 module on eBay (cca. $1) like this one:
http://www.ebay.com/itm/DS3231-AT24C32-IIC-Modul-High-Precision-Real-Time-Clock-Module-Arduino-New-/292041844936?hash=item43ff0ce8c8:g:d80AAOSwdGFYtsFP
Put battery in module.
Shutdown and powerof OPi and connect module:
Orange (i2c0 bus) RTC module (DS3231 RTC + 24C32 eeprom) 1 3.3V 2 VCC 3 PA12 (TWI0_SDA/DI_RX/PA_EINT12) 3 SDA 5 PA11 (TWI0_SCK/DI_TX/PA_EINT11) 4 SCL 9 GND 1 GND Power up OPi
Install i2c-tools.
sudo apt install i2c-tools Type command:
i2cdetect -y 0 You should see:
0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- This means that module is connected properly and that we have DS3231 on address 0x68 and eeprom 24C32 on address 0x57.
Type:
sudo echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device i2cdetect -y 0 You should see:
0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- This means that system is now using our RTC. Also, now should exist new device /dev/rtc1
Be sure that your system time is right, and type:
sudo hwclock -w -f /dev/rtc1 Now our RTC must have right time. Check with:
sudo hwclock -r -f /dev/rtc1 If everithing was ok, copy /sbin/fake-hwclock to bacup (just in case)
sudo cp ~/programming/sh/fake_hwclock/sbin/fake-hwclock /sbin/fake-hwclock Edit /sbin/fake-hwclock and place this code in it:
Reboot.
Now you should have right system time backed up by RTC.
 

Oh sorry i didn´t saw your post. My fan script is now:
 
#!/bin/bash if [ ! -d /sys/class/pwm/pwmchip1/pwm0 ]; then echo 0 > /sys/class/pwm/pwmchip1/export fi sleep 1 while [ ! -d /sys/class/pwm/pwmchip1/pwm0 ]; do sleep 1 done ISENABLE=`cat /sys/class/pwm/pwmchip1/pwm0/enable` if [ $ISENABLE -eq 1 ]; then echo 0 > /sys/class/pwm/pwmchip1/pwm0/enable fi echo 50000 > /sys/class/pwm/pwmchip1/pwm0/period echo 1 > /sys/class/pwm/pwmchip1/pwm0/enable # max speed run 60s echo 0 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle sleep 5 echo 50000 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle declare -a CpuTemps=(45000 40000 38000 30000 28000 0) declare -a PwmDutyCycles=(1000 5000 10000 15000 30000) while true do temp=$(cat /sys/class/thermal/thermal_zone0/temp) for i in 0 1 2 3 4 5; do if [ $temp -gt ${CpuTemps[$i]} ]; then DUTY=${PwmDutyCycles[$i]} echo $DUTY > "/sys/class/pwm/pwmchip1/pwm0/duty_cycle"; echo "temp: $temp, target: ${CpuTemps[$i]}, duty: $DUTY" break fi done sleep 1s; done Do you see something if you go to /sys/class/pwm/pwmchip1?  And do you have installed wiring orangepi from:  https://github.com/orangepi-xunlong/wiringOP ?? what does the command gpio readall shows?

I confirm.
I have updated to 5.6.10. Bluetooth doesn't work now.
 
PS: this hack helped me again.
PSS: now there is no sound from the 3.5 Jack. I didn't find how to fix it. I don't want to roll back to the old kernel.

Look like you install image and dtb correctly,but you edit armbianEnv.txt not correctly or put overlay-user files not correctly.(Oh,I see my previous post,I spell error,should 'sudo apt install bluez')
Yes,this is not easy for simple user.I edit dts include bluetooth and not need add 'overlay-user',so:
restore your armbianEnv.txt install following dtb files reboot And should see:
root@orangepi4:~# dmesg |grep Blue [ 3.982085] Bluetooth: Core ver 2.22 [ 3.982126] Bluetooth: HCI device and connection manager initialized [ 3.982135] Bluetooth: HCI socket layer initialized [ 3.982140] Bluetooth: L2CAP socket layer initialized [ 3.982150] Bluetooth: SCO socket layer initialized [ 3.988355] Bluetooth: HCI UART driver ver 2.3 [ 3.988359] Bluetooth: HCI UART protocol H4 registered [ 3.990827] Bluetooth: HCI UART protocol Broadcom registered [ 4.341819] Bluetooth: hci0: BCM: chip id 130 [ 4.342164] Bluetooth: hci0: BCM: features 0x0f [ 4.344286] Bluetooth: hci0: BCM4345C5 [ 4.344299] Bluetooth: hci0: BCM4345C5 (003.006.006) build 0000 [ 5.045748] Bluetooth: hci0: BCM4345C5 (003.006.006) build 0038 root@orangepi4:~# hciconfig hci0: Type: Primary Bus: UART BD Address: 43:45:C5:00:1F:CA ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING PSCAN RX bytes:397051100 acl:654339 sco:0 events:741 errors:0 TX bytes:42146 acl:432 sco:0 commands:258 errors:0  
OrangePi4-Image-dtb-v2.zip

I saved the file in my home dir as pwm-fan.sh and run it as administrator with
bash ./pwm-fan.sh And the fan spins up full speed but after that it stops running. Even when the temperature is over the 30 degrees celsius. I have changed 48000 in the above script to 30000. So i think there is also something else to change but i have no idea what. Who could help me?

I measured the consumption of the OP4 board:
1.Loading the operating system
 
2.The system is loaded, there is no application load
 
3. 7z benchmark. Maximum CPU load.
 

About the Orangepi 4 's bluetooth chip AP6256,I read hci how get bluetooth mac address from 'https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/bluetooth/btbcm.c',the origin firmware file /lib/firmware/brcm/BCM4345C5.hcd include default mac address '43:45:C5:00:1F:AC',it is cause driver mark it 'HCI_QUIRK_INVALID_BDADDR',so I use hex editer change the  default mac to '43:45:C5:00:1F:CA',you can use this firmware file replace /lib/firmware/brcm/BCM4345C5.hcd and not need do 'btmgmt --index 0 public-addr 11:22:33:44:55:66' set bluetooth mac after boot.
BCM4345C5.hcd

I measured the consumption of the OP4 board:
1.Loading the operating system
 
2.The system is loaded, there is no application load
 
3. 7z benchmark. Maximum CPU load.
 

Well done!
 
I have added your patches with minor tweaks to the Armbian build system - it will be available in the images from the download area... at some point ;-)

Yes,please back up your old files
orangepi4-sound-bt.zip

Yes,the orange pi 4's bluetooth also fixed.
the main line kernel support bcm bt chip,so I use the kernel driver  and not use brcm_patchram_plus file do this.
the 'wireless-wlan' and 'wireless-bluetooth' in dts,it is from rockchip's net/rfkill/rfkill-bt.c and net/rfkill/rfkill-wlan.c and this not found in main line kernel,so  'wireless-wlan' and 'wireless-bluetooth' should remove or disable,and wifi be driver by sdio node in dts.
the bluetooth will  be driver by uart->bluetooth->compatible = "brcm,bcm4345c5"(serial@ff180000->bluetooth->compatible = "brcm,bcm4345c5")
and the kernel config should enable CONFIG_SERIAL_DEV_BUS=y CONFIG_SERIAL_DEV_CTRL_TTYPORT=y CONFIG_BT_HCIUART_BCM=y CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y
 
but have a little problem,need  do 'btmgmt --index 0 public-addr 11:22:33:44:55:66' set bt mac after boot,otherwise hciconfig will show 'DOWN RAW',someone konw fix this?
 
I did some dts over and hope this can help armbian fix 
bluetooth-opi4.dts linux-rockchip64-current.config

Oh,I fixed this problem spend 2 weeks,I finally heard sound from 3.5 mm jack (this jack is OMTP otherwise need keep press headphone button)
 
I see this topic,and I compair https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/codecs/rt5640.c and https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/codecs/rt5651.c,this rt5651 not enable mclk and orangepi4"s rt5651 linked i2s1,the i2s1's SCLK_I2S_8CH parent not SCLK_I2S1_8CH defult and need set alsamixer in following(also use alsactl save this alsamixer state):
amixer set 'HPO L' on amixer set 'HPO R' on amixer set 'HPOVOL L' on amixer set 'HPOVOL R' on amixer set 'HPO MIX HPVOL' on amixer set 'OUT MIXL DAC L1' on amixer set 'OUT MIXR DAC R1' on amixer set 'Stereo DAC MIXL DAC L1' on amixer set 'Stereo DAC MIXR DAC R1' on And I not familiar with electronics,I did some patch and hope this can help armbian fix 
fix-i2s1-clk.patch orangepi4-rt5651.patch orangepi4-i2s_8ch_mclk.dts
Armbian applied this patch to 'Armbian build system' and with minor tweaks,you can use it by 'Armbian build system' latest branch.

sound fixed

I found the answer to my question. Working library for Orange PI 4:
https://github.com/orangepi-xunlong/wiringOP
 
 

DVFS works fine on a patched 4.12.0, but on OPi-Prime. If you need I may send patches.

I have the 5.27 revision kernel files with a working cpufreq, DEB files attached 
linux-dtb-dev-sun50iw2_5.27_arm64.deb
linux-headers-dev-sun50iw2_5.27_arm64.deb
linux-image-dev-sun50iw2_5.27_arm64.deb
linux-u-boot-dev-orangepipc2_5.27_arm64.deb

Wait (1 week or more) until migration to 4.11 is completed or use a previous nightly image with kernel 4.10