firepower

I was looking at the v4l2 patches for chromium. I think we can apply this to cedrus.
 
First, we apply these two patches.
https://github.com/armbian/build/blob/f55a87d469b0634f72bc857f773a52a466f66292/patch/kernel/archive/rockchip64-6.6/media-0001-dma-mapping-let-dma_alloc_noncontiguous-allow-DMA_AT.patch
https://github.com/armbian/build/blob/f55a87d469b0634f72bc857f773a52a466f66292/patch/kernel/archive/rockchip64-6.6/media-0002-Enable-non-coherent-dst-bufs-for-Hantro-V4L2-driver.patch
 
 
For the last patch we replace it with our own by editing /drivers/staging/media/sunxi/cedrus/cedrus_video.c and adding "dst_vq->allow_cache_hints = 1;".  You will see it at the very bottom of the cedrus_video.c file.
 
 https://github.com/armbian/build/blob/f55a87d469b0634f72bc857f773a52a466f66292/patch/kernel/archive/rockchip64-6.6/media-0003-Enable-non-coherent-dst-bufs-for-Rkvdec-V4L2-driver.patch
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 From: amazingfate <liujianfeng1994@gmail.com> Date: Fri, 3 Nov 2023 18:07:24 +0800 Subject: Enable non-coherent dst bufs for Rkvdec V4L2 driver --- drivers/staging/media/rkvdec/rkvdec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/media/rkvdec/rkvdec.c b/drivers/staging/media/rkvdec/rkvdec.c index 84a41792cb4b..b35f7e1b8a20 100644 --- a/drivers/staging/media/rkvdec/rkvdec.c +++ b/drivers/staging/media/rkvdec/rkvdec.c @@ -755,6 +755,7 @@ static int rkvdec_queue_init(void *priv, dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; dst_vq->lock = &rkvdec->vdev_lock; dst_vq->dev = rkvdec->v4l2_dev.dev; + dst_vq->allow_cache_hints = 1; return vb2_queue_init(dst_vq); } -- Armbian  
 
https://github.com/torvalds/linux/blob/master/drivers/staging/media/sunxi/cedrus/cedrus_video.c
dst_vq->dev = ctx->dev->dev; dst_vq->allow_cache_hints = 1; return vb2_queue_init(dst_vq); }  
 
https://github.com/armbian/build/pull/5883
Then we have to create our own udev rules.
SUBSYSTEM=="video4linux", ATTR{name}=="rockchip,rk3568-vpu-dec", SYMLINK+="video-dec%n" SUBSYSTEM=="media", ATTR{model}=="hantro-vpu", SYMLINK+="media-dec%n"  
This is from H6 dtsi... I think we need to add this to the h616 dtsi to get the hantro-vpu module to load.
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
video-codec-g2@1c00000 { compatible = "allwinner,sun50i-h6-vpu-g2"; reg = <0x01c00000 0x1000>; interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_VP9>, <&ccu CLK_VP9>; clock-names = "bus", "mod"; resets = <&ccu RST_BUS_VP9>; iommus = <&iommu 5>; };  
if you see something like this in your dmesg then we are on right track.
https://forum.banana-pi.org/t/bpi-r2-pro-ubuntu-vpu-support-decode-and-encode/13776/16
 
 
We might need to use ubuntu's version of chromium? Not sure if the debian version is patched for v4l2.
https://github.com/saiarcot895/chromium-ubuntu-build/issues/65
 

Figured it out, using pishrink, finally! It takes a while because 28 GB of empty space are being copied in the beginning, but anyhow ;-)
This is my procedure:
 
1) boot from "plain" armbian (#2, see above)
2) insert original SD card (#1, 32 GB) in reader
3) dd if=/dev/sd#1 of=/path/to/image.img
4) pishrink.sh /path/to/image.img
5)dd if=/path/to/image.img of=/dev/sd#3, #3 being the backup SD card, 16 GB
 
note: "#1", e.g. is "/dev/sda", not "/dev/sda1", since you need to do a block level copy of the device, not only the disk.

Tested in Transpeed 8k H618 4g 64g & Vontar 6k h618  4g 32g

@Nick A As we talk, here are the final "howto" to make it working leds display with openvfd. If you find any problem tell me.
 
First go to armbian-config to change some kernel with has his own headers available like 6.10.9 (i had problem with rebooting with 6.7.12) configure an internet connection unpack the attached file to root dir / cd /linux_openvfd cp openvfd.dts /boot/dtb/allwinner/overlay/ armbian-add-overlay /boot/dtb/allwinner/overlay/openvfd.dts reboot ln -sf /boot/System.map-$(uname -r) /lib/modules/$(uname -r)/build/System.map cd cd /linux_openvfd/driver make -j 4 depmod -a make modules_install modprobe openvfd cd .. chmod +x OpenVFDService cp OpenVFDService /usr/sbin/ cp openvfd.service /etc/systemd/system/openvfd.service #apt install python3-psutil systemctl enable openvfd.service systemctl start openvfd.service After this, openvfd is working but if you want my scroll.py as a service uncomment in openvfd.service and comment the existing one. #ExecStart=/bin/sh -c '[ `cat /proc/device-tree/openvfd/compatible` = "open,vfd" ] && /sbin/modprobe openvfd; python3 /linux_openvfd/scroll.py'  
Correct openvfd.dts, some compiling fixes and extra glyphs for cool animations added to this file. 
linux_openvfd.zip
 
 
@Nick A Please let me know if you make a new release with kernel 6.9.12 with this working cos now i made my server but no hdmi and no ethernet in 6.10. 
 

For Transpeed 8k  in order to make your IR remote to work with Armbian  (it may works and with other H618 boxes, but i test it only on Transpeed 8k)
 
do the following steps:
1> sudo apt-get install ir-keytable
2> copy the attached file transpeed-8k.toml to /etc/rc_keymaps/protocols/
 
3>  add the following line to your /etc/rc.local
     ir-keytable -p NEC -w /etc/rc_keymaps/protocols/transpeed-8k.toml
 
It works with mpv / vlc /celluloid.
 
Note: you can add any remote you have to your box by playing with ir-keytable is a very useful tool.
 

transpeed-8k.toml

What you are referring as "android" dts is nothing more than a device tree wrote for a very old Linux kernel (probably 3.10 or 3.14).
As long as things change during time, so the device tree specifications become more standardized and well-defined. Device trees for old kernels (3.10 is very old nowadyas) are very messy and generally harder to read and understand.

Transpeed 8k618-t & Vontar H618
Wifi: HK6334Q
Clock: 37.4 MHz
 
Tanix Tx6s & Tx6
Wifi: SP6330-X0
Clock: 26.0 MHz
 
Tanix TX68
Wifi: AW869A
Clock: No Osc  

This is something hopefully suitable to become a 'Board Bring up' thread.
 
The NanoPC T4 was the smallest RK3399 board around featuring full set of interfaces (Rock960 was smaller but there you can't use GbE without a proprietary expander) but in the meantime he got two smaller siblings: NanoPi M4 and the cute NEO4.
 
Pros:
Another RK3399 board so software support is already pretty mature Rich set of interfaces (2 x USB2 without shared bandwidth, 2 x USB3, triple display output and so on) No powering hassles due to 12V (2A) PSU requirement 16GB superfast eMMC 5.1  Usable and performant Wi-Fi (dual band and dual antenna so MIMO can be used, for numbers see here) All 4 PCIe lanes exposed (M.2 M key connector on the bottom, suitable for NVMe SSDs, or to attach a 4 port SATA controller or a PCIe riser card)  
Cons:
A bit pricey (but if you compare with RockPro64 for example and order all Add-Ons you end up with a similar price) High idle consumption (4W PSU included in idle), maybe this is just bad settings we can improve over time heatsink too small for continous loads  
I started relying on @hjc's work since he's currently using different kernels than we use on RockPro64 or ODROID-N1 (though all the 4.4 kernels are more or less just RK's 4.4 LTS branch with some modifications, with mainline I didn't had a look what's different in Heiko's tree and 'true' mainline).
 
Tinymembench numbers with RK 4.4 vs. mainline kernel (the latter both showing lower latency and higher bandwidth).
 
Internal 16 GB eMMC performance:
eMMC / ext4 / iozone random random kB reclen write rewrite read reread read write 102400 4 23400 28554 26356 26143 27061 29546 102400 16 48364 48810 85421 85847 84017 47607 102400 512 48789 49075 273380 275699 258495 47858 102400 1024 48939 49053 290198 291462 270699 48099 102400 16384 48673 49050 295690 295705 294706 48966 1024000 16384 49243 49238 298010 298443 299018 49255 That's what's to be expected with 16 GB and exactly same numbers as I generated on ODROID-N1 with 16 GB size. When checking SD card performance it maxed out at 23.5 MB/s which is an indication that no higher speed modes are enabled (and according to schematics not possible since not able to switch to 1.8V here -- I didn't try to adjust DT like with ODROID-N1 where SDR104 mode is possible which led to some nice speed improvements when using a fast card -- see here and there)
 
Quick USB3 performance test via the USB-3A port:
Rockchip 4.4.132 random random kB reclen write rewrite read reread read write 102400 4 24818 29815 33896 34016 24308 28656 102400 16 79104 90640 107607 108892 80643 89896 102400 512 286583 288045 285021 293431 285016 298604 102400 1024 315033 322207 320545 330923 320888 327650 102400 16384 358314 353818 371869 384292 383404 354743 1024000 16384 378748 381709 383865 384704 384113 381574 mmind 4.17.0-rc6-firefly random random kB reclen write rewrite read reread read write 102400 4 37532 42871 22224 21533 21483 39841 102400 16 86016 104508 87895 87253 84424 102194 102400 512 274257 294262 287394 296589 287757 304003 102400 1024 294051 312527 317703 323938 323353 325371 102400 16384 296354 340272 336480 352221 339591 340985 1024000 16384 367949 189404 328094 330342 328136 139675 This was with an ASM1153 enclosure which shows slightly lower numbers than my usual JMS567 (all currently busy with other stuff). Performance with RK 4.4 kernel as expected, with mainline lower for whatever reasons. I also tried to test with my VIA VL716 enclosure directly attached to the USB-C port but ran into similar issues as with RockPro64 but since my enclosure and the cable also show problems when using at a MacBook Pro I suspect I should blame the hardware here and not USB-C PHY problems with RK3399.
 
This is NanoPC T4 with vendor's heatsink, lying flat on a surface that allows for some airflow below, running cpuburn-a53 on all 6 cores after half an hour:
13:57:31: 1008/1416MHz 8.44 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:40: 1008/1416MHz 8.52 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:48: 1008/1416MHz 8.51 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:57: 1200/1416MHz 8.47 100% 0% 99% 0% 0% 0% 90.6°C 0/5 13:58:05: 1200/1416MHz 8.47 100% 0% 99% 0% 0% 0% 91.1°C 0/5 So with heavy workloads you most probably need a fan to prevent throttling. 
 
Development related questions: IMO we should try to rely on single sources for all the various RK3399 boards that are now available or will be soon. And I would prefer ayufan's since he's somewhat in contact with RK guys and there's a lot of great information/feeback provided by TL Lim. What do others think?
 
Also an issue is IRQ affinity since on boards where PCIe is in use those interrupts should clearly end up on one of the big cores while on other boards USB3 and network IRQs are better candidates. I already talked about this with @Xalius ages ago and most probably the best idea is to switch from static IRQ affinity set at boot by armbian-hardware-optimization to a daemon that analyzes IRQ situation every minute and adopts then dynamically the best strategy.
 
Wrt information for endusers. All RK3399 boards basically behave the same since the relevant stuff is inside the SoC. There's only different DRAM (matters with regard to consumption and performance), different interfaces exposed and different power circuitry (and obviously different settings like e.g. cpufreq behaviour but I think we should consolidate those for all RK3399 boards). So you already find a lot of information in my ODROID-N1 'review', my SBC storage performance overview and most probably also a lot around RockPro64. No idea where to inform about RK3399 GPU/VPU stuff since not interested in these areas at all (hope others add references or direct information).