drice

It appears to be decompression of initramfs taking 31 seconds:
 
[ 6.147142] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 6.148094] PCI: CLS 0 bytes, default 64 [ 6.158734] Trying to unpack rootfs image as initramfs... [ 35.413752] Freeing initrd memory: 7632K [ 35.462578] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available [ 35.482492] hw perfevents: enabled with armv8_cortex_a72 PMU driver, 7 counters available I suspect this is due to the CPU starting at a very slow clock speed. The speed of these algorithms should be much faster:
 
[ 4.104906] raid6: neonx8 gen() 26 MB/s [ 4.172463] raid6: neonx8 xor() 21 MB/s [ 4.242370] raid6: neonx4 gen() 27 MB/s [ 4.309700] raid6: neonx4 xor() 21 MB/s [ 4.379941] raid6: neonx2 gen() 20 MB/s [ 4.446522] raid6: neonx2 xor() 19 MB/s [ 4.517607] raid6: neonx1 gen() 12 MB/s [ 4.583751] raid6: neonx1 xor() 14 MB/s [ 4.653424] raid6: int64x8 gen() 14 MB/s [ 4.721122] raid6: int64x8 xor() 9 MB/s [ 4.790970] raid6: int64x4 gen() 15 MB/s [ 4.860366] raid6: int64x4 xor() 10 MB/s [ 4.934680] raid6: int64x2 gen() 10 MB/s [ 5.003469] raid6: int64x2 xor() 8 MB/s [ 5.079205] raid6: int64x1 gen() 6 MB/s [ 5.151255] raid6: int64x1 xor() 6 MB/s [ 5.151948] raid6: using algorithm neonx4 gen() 27 MB/s I don't know how to check or control the initial speed of the CPU when the system is booting.

I uses my NanoPi M4 as a cheap ARM64 kvm host, and I need a newer kernel since the legacy one is kind of broken in terms of KVM.
 
But Wi-Fi is not working in dev kernel for quite some time, I found a temporary fix for that:
 
# cd /lib/firmware/brcm
# mv brcmfmac4356-sdio.bin brcmfmac4356-sdio-orig.bin
# ln -s ../rkwifi/fw_bcm4356a2_ag.bin brcmfmac4356-sdio.bin
# ln -s ../rkwifi/nvram_ap6356s.txt brcmfmac4356-sdio.friendlyelec,nanopi-m4.txt
 
Then reboot, Wi-Fi will be back.

https://gitlab.freedesktop.org/lima/mesa/issues/85#note_213894
 
as said by Lima maintainer: Qiang Yu, xfce4 runs OK on lima now
 
we could start to integrate lima to Armbian.
 
@Igor do you agree?

It was not easy at all to come to this point. A lot of new code was written for ffmpeg, cedrus and Kodi to make it work. But since LibreELEC is closed ecosystem, we can afford to make some hacks which would otherwise cause issues with other programs.
 
Anyway, I plan to rework some Cedrus patches these days to remove at least one hack and after that I can try to help you with using that special version of ffmpeg. Reportedly it works fine with unmodified mpv but I didn't test that yet. However, be prepared to pick a lot of patches from latest linux git master. Unfortunately, this is moving target and modified ffmpeg will work with only specific version of Cedrus driver.
 
Once you are able to match ffmpeg and Cedrus driver it's best not to change anything until you have good reason to do so, like extending driver with new features.

This looks similar to the issue in this post:
CPU stall followed by clock getting set to an incorrect time. I think the clock issue is a symptom rather than a cause. I didn't see anything obvious in the call stack of this issue or the referenced issue but I'm not very good at reading those. Maybe someone who knows more can compare these posts and see if a root cause is obvious.

After doing a lot of reading (documentation and code) regarding the Cedrus driver (sunxi-cedrus), LibVA V4L2 Request API driver (libva-v4l2-request), VA-API, and interfacing with video players, I think most of the work will involve VA-API and interfacing with the video players. Or more precisely, updating the video players to interface with the LibVA driver in a way that works with the V4L2 Request API. Based on my testing, the Cedrus driver in sunxi-dev (5.2.6 - MPEG2 only) is working with the native V4L2 Request API as shown by testing with v4l2-request-test and the preset slice data included with that tool. When I run the test, I get hardware accelerated full screen output via DRM.
 
But so far I haven't been able to get any video playback to work with VA-API in mpv or vlc. mpv fails with "device or resource busy" when calling v4l2_set_format() in X11 and says that the hardware decoder isn't compatible with DRM. vlc fails after rendering the first frame with "buffer deadlock prevented". I still have more reading to do, and I have a few things to try that would be as simple as compiling the players with a few additional options set. But if that doesn't work this could end up being a complicated problem to solve.