gounthar

The kernel got correctly updated tonight.
 
Welcome to Armbian 22.02.1 Focal with bleeding edge Linux 5.16.10-bcm2711 Docker now works.
Thanks a lot for your work.

I'd consider this one ... https://www.hardkernel.com/shop/odroid-xu4-special-price/ 

https://github.com/armbian/build/pull/3502

Yes, hw decoding works out of the box for mainline linux kernel.

Thank you for your generosity! 
 
The Armbian community is doing a really great job. I am still grateful for all the help I found here when I had a problem with my Helios64. (Remember that? https://forum.armbian.com/topic/18855-upgrading-to-bullseye-troubleshooting-armbian-21081/?do=findComment&comment=129711 )
 
 
Today I'm not coming to ask for help (since my NAS is working perfectly fine!) but to say hi to everyone.
 
And reading your positive message, Amix73, you even made me want to make a small donation. 
 
Thanks again, everyone!
 

5.10 is ancient for video decoding purposes. Codecs started stabilizing after 5.11. With 5.14 you'll have stable and fully working MPEG2, VP8 and H264. If you need low effort solution, build latest gstreamer 1.20 RC with gst-plugins-bad with one of the latest kernels. With proper pipeline, it works. If you need out of the box solution, use LibreELEC distro.

Hi all. In this video I show how to install Open Media Vault on your SBC with Armbian Buster.
I've used the Odroid HC4, this is the same for any board you'd like to use. 
Here my video.
Greetings.
NicoD

It is possible that there are some options missing from armbianEnv.txt. On my Banana Pi M2 Zero, beyond setting the overlays, some additional settings had to be added to armbianEnv.txt. These options are:
param_spidev_spi_bus=1 param_spidev_spi_cs=0 If I understood the page about the OrangePi Zero (https://linux-sunxi.org/Xunlong_Orange_Pi_Zero), using BUS 1 and CS 0 should work (however, I don't have one to test).
 
You can find a more complete description about all possible parameters for armbianEnv.txt for the H3 on the page https://github.com/armbian/sunxi-DT-overlays/tree/master/sun8i-h3

Moved to Common issues / peer to peer technical support since unsupported image/build.

ver 20211219 kernel 5.15.10
fan work

Your GPS module may contain a well disciplined temperature compensated RTC and oscillator (most do), and there is a possibility that it may be able to provide accurate PPS output and NMEA time messages for a period even if there is no GPS signal, if programmed to do it.  (This is called holdover mode and some modules can do it, although the affordable ones may not offer this).

Many years ago I made PPS generator with a quartz xtal in an oven composed of a large TO220 transistor clamped to the xtal and surrounded by polystyrene.  The transistor was it's own temperature sensor, and the simple circuit maintained a steady temperature.  An 8048 programmed in assembler divided the oscillator down to 1Hz and added an extra unit to the division every now and then to compensate for the quantization error to get a final drift of about 4 parts per million.

The oven used the same principal as the link below, but the bigger transistor gave a better thermal coupling.  Something like this could provide stable temperature for any RTC.  https://www.romanblack.com/xoven.htm

Hi gounthar,
Sorry that I'm way to late to this party.  But if you are still interested.... 

I've built a GPS disciplined time server using ESP8266.  Jitter is way too high, the onboard oscillator is jittery and the WiFi module has variable latency.

I'll link you to a tutorial that I wrote for GPS discipline on OrangePi zero (should work for other boards to)
I get jitter of less than +- 20 microseconds with temperature control at 57 degrees C  about +-60 microseconds without temperature control.

EDIT: I read my tutorial again and note that you already responded to it. 
I'll leave this here in case it's useful to others finding your thread.
 

A few months back I came across something interesting on David Taylor's web site.
A shell script to control the temperature of a SBC using the heat generated by the CPU.
Of course if your clock oscillator is integrated into the CPU then this is a way to control it's temperature and theoretically get more accurate time.
I tried this and it worked really well with a few tweaks.  I liked it so scripted it as a service.
I'm getting a maximum offset of less than +-20 micro seconds

http://www.satsignal.eu/ntp/Raspberry-Pi-ntpheat.html
 
#!/usr/bin/env python # # Requires python3 # generate some heat! # # Run ntpheat in the background. # It will try to stabilize the CPU temperature at 54C by default. # Sometimes one copy of ntpheat can use 100% of one CPU and #!/usr/bin/env python # # generate some heat! # # Run ntpheat in the background. # It will try to stabilize the CPU temperature at 54C by default. # Sometimes one copy of ntpheat can use 100% of one CPU and # still not heat up your Pi as much as you want. The temptation # is to add more insulation to your Pi, but then it will overshoot # your target temperature if your load factor goes high. # # The solution is to run more than one copy of ntpheat. This is # easy to do with the -c option. # # To run 3 copies of ntpheat: ntpheat -c 3 import argparse import hashlib import os import sys import time # Work with argvars parser = argparse.ArgumentParser(description="make heat") parser.add_argument('-c', '--copies', default=[1], dest='copies', help="Number of copies to run. Default is 1", nargs=1, type=int) parser.add_argument('-t', '--temp', default=[57.0], dest='target_temp', help="Temperature to hold. Default is 57.0", nargs=1, type=float) parser.add_argument('-w', '--wait', default=[0.001], dest='wait', help="Set delay time in seconds, default is 0.1", nargs=1, type=float) args = parser.parse_args() args.copies[0] -= 1 while args.copies[0]: args.copies[0] -= 1 pid = os.fork() if pid: # I am the fork break zone0 = '/sys/class/thermal/thermal_zone0/temp' cnt = 0 m = hashlib.md5() temp = 0 max_cnt = args.wait[0] * 100000 # on a RasPi 3 the temp steps seem to be about 0.537 to 0.539C temp_gate = args.target_temp[0] while True: # on a RasPi 3, 200,000 of the m.update() can be one second delta = temp_gate - temp if 0 < delta: # heat it up my_str = "Time is an illusion. Lunchtime doubly so." my_enc = my_str.encode('utf-8') m.update(my_enc) else: cnt = max_cnt # cools off slower than it heats up. # undocumented Python 'feature', no sleep less than 1 milli Sec sleep = args.wait[0] * 10.0 * -delta if 0.001 > sleep: sleep = 0.001 time.sleep(sleep) cnt += 1 # read the temperature every max_cnt if max_cnt < cnt: cnt = 0 zone_data = open(zone0, 'r') for line in zone_data: temp = float(line) / 1000 zone_data.close() The service file: ntpheat.service - if you don't know how to set up a systemd service then go here https://wiki.debian.org/systemd/Services
[Unit] Description=ntpheat [Service] ExecStart=/usr/bin/ntpheat.sh Restart=on-failure [Install] WantedBy=multi-user.target  

 
I should add:  To make the CPU based temperature control work, there must be no CPU intensive processes at all.  This means disabling any cron jobs that load the CPU or forcing them to use less CPU over a longer period.
To do this you need cgroup-tools
 
#spread out heating caused by scheduled maintenance on NTP server #get package sudo apt-get install -y cgroup-tools #create a cpu group called cpulimit sudo cgcreate -g cpu:/cpulimit #set cpulimit group limit to 100000uS out of 1000000uS (= 10% of CPU cycles) sudo cgset -r cpu.cfs_period_us=1000000 cpulimit sudo cgset -r cpu.cfs_quota_us=100000 cpulimit #check settings sudo cgget -g cpu:cpulimit #to limit your process start it as follows - sudo cgexec -g cpu:cpulimit YOUR_COMMAND
You can use this to run CPU intensive jobs at 10%
To reconfigure some cron jobs:
 
/etc/cron.d/armbian-updates @daily root cgexec -g cpu:cpulimit /usr/lib/armbian/armbian-apt-updates
Some cron jobs run scripts:
#for some cron scripts: /etc/cron.daily/apt-show-versions cgexec -g cpu:cpulimit apt-show-versions -i /etc/cron.daily/sysstat cgexec -g cpu:cpulimit exec /usr/lib/sysstat/sa2 -A Apt xapian index is a hog...  limit it to 5%
#create a cpu group called cpulimit5 (for 5% CPU) sudo cgcreate -g cpu:/cpulimit5 #set cpulimit group limit to 25000uS out of 500000uS (= 5% of CPU cycles) for bad process. sudo cgset -r cpu.cfs_period_us=500000 cpulimit5 sudo cgset -r cpu.cfs_quota_us=25000 cpulimit5 /etc/cron.weekly/apt-xapian-index - comment out all except top line and replace with cgexec -g cpu:cpulimit5 /usr/sbin/update-apt-xapian-index
 

The documentation on the Orange Pi Zero Plus 2 is somewhat scarce. I couldn't find information on the GPIO map for the 26-pin header anywhere, but I manually mapped it. I did this with an LED on each successive pin and testing through the /sys/class/gpio driver until I found the one to control it. This caused a bunch of resets and eventually corrupted my sd card, but I got the info
 
Each of the numbers below is the GPIO number used for /sys/class/gpio. For example, 110 means gpio110. The list is by pin number from 1 to 26. A value of -1 means unavailable (as far as I could discover):
 
-1, -1, 12, -1  (pin 1,2,3,4)
11,-1,6,0 (pin 5,6,7,8)
-1,1,352,107 (pin 9,10,11,12)
353,-1,3,19 (pin 13,14,15,16)
-1,18,-1,-1 (pin 17,18,19,20)
-1,2,14,13 (pin 21,22,23,24)
-1,110 (pin 25, 26)
 
I've added this table to my SPI_LCD project to make it easier to use for generic GPIO access without having know the details of working with the sysfs kernel driver: https://github.com/bitbank2/SPI_LCD
 
P.S. The red LED on the board is mapped to GPIO17
 

OK, so no answers  Well as usual I pressed on. My first mistake was using JNA generation (but it was easy), so I researched JNI. Well JNI is very cumbersome to do by hand, so I looked for a JNI code generator and found one call HawtJNI. Of course it wouldn't work with Java 11 which is the Java LTS version, so I created a fork. Use the JDK11 branch if you want to play with it because I don't know if the PR will be accepted. I started wrapping c-periphery since it now supports the new /dev/gpiochip way of accessing the GPIO chips. I ran a performance test (I validated on a scope) and I'm getting ~235 KHz on a v1 Nano Pi Duo! That's over 500K writes per second compared to 2K using JNA and libgpiod. Even python-periphery yields ~37 KHz which is a pure Python version.
 
Any ways exciting news for bit bangers of the world or anyone needing high performance GPIO. Once I have the GPIO code working I'll post on my Github site and announce. Since Bulldog only supports three boards this is good news for Armbian folks with a wider array of supported boards. I still need to test ARMv8 64 bit.

@orangepie14
 

..about power outages..
 
I had this problem years argo also.
I run a server (Orange Pi PC) 24/7 in a area with a lot of "power outages".

I prevent this with a board like this: Double 18650 Lithium-Batterie Schild V8 Mobile Power bank
 
 
 
You have only to connect it between your power source and you Pi.
 
That's all..
 
Markus

Use:
 
 ./compile.sh CREATE_PATCHES="yes"
change sources when asked and a patch will be created / updated. Once done, copy that patch to the patck/kernel/sunxi64-edge/ folder and pay attention to the patch executing order. Hint - if you need that patch is executed last, add higher number or simply xx in front of the patch filename.
 
For adding an overlay, check this patch: https://github.com/armbian/build/blob/master/patch/kernel/archive/sunxi-5.15/general-sunxi-overlays.patch

I did next few moves:
Change sun8i-r40.dtsi  
Change sun8i-r40-bananapi-m2-ultra.dts  
Compile ffmpeg (options you can get from log message above) Compile codec driver sunxi-cedar Remove cma option from kernel command line (it cause conflict with SRAM described in DTS)

Orange Pi Zero NTP Stratum 1 PPS GPS Server with Armbian OS.
Link to the Tutorial - http://schwartzel.eu3.org/ntp-stratum1.html

This tutorial uses a 3.3V capable GPS module with PPS output - TOPGNSS GN-701 (u-blox 7) but other similar modules should work.

 
This tutorial is for the Orange Pi Zero, but will probably work for other boards.

 

I couldn't easily do a comprehensive hardware and software tutorial on this forum, so I've published it on my web server and linked from here and attached a PDF.
Link to the Tutorial - http://schwartzel.eu3.org/ntp-stratum1.html

Tutorial PDF
ntp-stratum1.pdf

If you spot any typo's or errors please let me know.
 

Thanks for your answer. I will try again to enable

I was following this posts:
and:
https://wvthoog.nl/nanopi-ov5640-camera/
 
1. decompile dtb to dts
2. modify dts: 1) add reversed-memory, 2) disable cedrus, add cedar_ve
3. compile dts to dtb, reboot
4. /dev/cedar_ve appear
5. run ffmpeg

Hi,
I've tested your code on an OrangepiP. It can encode h264 1080p at 28fps.
 
root@orangepipc:~/FFmpeg# ./ffmpeg -s 1920x1080 -pix_fmt nv12 -f rawvideo -stream_loop -1 -i xilinx_1080p_nv12.yuv -pix_fmt nv12 -c:v cedrus264 -f null -
ffmpeg version N-103905-gafd516bd9c Copyright (c) 2000-2021 the FFmpeg developers
  built with gcc 8 (Debian 8.3.0-6)
  configuration: --enable-nonfree --enable-gpl --enable-version3 --enable-libx264 --enable-libmp3lame --enable-libpulse --enable-libv4l2
  libavutil      57.  7.100 / 57.  7.100
  libavcodec     59.  9.101 / 59.  9.101
  libavformat    59.  5.100 / 59.  5.100
  libavdevice    59.  0.101 / 59.  0.101
  libavfilter     8. 10.100 /  8. 10.100
  libswscale      6.  1.100 /  6.  1.100
  libswresample   4.  0.100 /  4.  0.100
  libpostproc    56.  0.100 / 56.  0.100
[rawvideo @ 0x27d72c0] Estimating duration from bitrate, this may be inaccurate
Input #0, rawvideo, from 'xilinx_1080p_nv12.yuv':
  Duration: 00:00:04.12, start: 0.000000, bitrate: 622080 kb/s
  Stream #0:0: Video: rawvideo (NV12 / 0x3231564E), nv12, 1920x1080, 622080 kb/s, 25 tbr, 25 tbn
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (cedrus264))
Press [q] to stop, [?] for help
[VDPAU SUNXI] VE version 0x1680 opened.
Output #0, null, to 'pipe:':
  Metadata:
    encoder         : Lavf59.5.100
  Stream #0:0: Video: h264, nv12(progressive), 1920x1080, q=2-31, 200 kb/s, 25 fps, 25 tbn
    Metadata:
      encoder         : Lavc59.9.101 cedrus264
frame=  465 fps= 28 q=-0.0 Lsize=N/A time=00:00:18.60 bitrate=N/A speed=1.12x
video:5560kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

@woodfecould you please to provide a detailed specs of your Orange Pi board and kernel to understand better about how to enable Cedrus VDPAU?

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.
 
 

Sold on Reddit.
 
Hello,
 
looking at selling my Helios64.

Mostly looking at getting a price check (what's the device still worth) and gauging interest.

Device is in pristine condition, standard fans were swapped for Noctua NF-A8. (standard fans will be included)
I'd prefer to keep this EU only as shipping is going to be a pain.