Ryzer

All Armbian board configurations files live in build/config/board/ Besides the Pcduino2 Cubieboard and OlinuXino-lime board, I don't know what other A10 boards still have some level of support. After that the next step would probably be to confirm that it works with uboot. Here you have another config file and dts. For any tweaks to uboot you will need to pass uboot-patch when running compile.sh. Note that when you do this you will need to open a new tab and navigate to cache/sources/u-boot-worktree/ Similiarly for the kernel you would navigate to cache/sources/kernel/ currently 6.12 is "current" while 6.14 is "edge" Hope this helps Ryzer

My mistake I was suggesting based on prior comments found on the Orange Pi Zero3 thread but after reviewing again it looks like the port part of the overlay is no longer necessary either so as Kris777 suggested just the interface name should hopefully now suffice. According to wiki, the main i2c interface should be i2c3: https://linux-sunxi.org/Xunlong_Orange_Pi_Zero2

HI, I dont believe it is necessary to recreate the Topwise A721 dts as it should already be included in the kernel sources used. What most likely needs to be done as a minimum is config file so that the Armbian build system recognizes the board and knows how to handle it. Admittedly I have never added a board so I can only speculate. A problem you may face is that the internal LCD may no longer work with the latest kernels. best of luck Ryzer

oh right, then maybe there is a few things you can help me with in future as I still getting to grips with my esp32. Don't worry it look difficult at first but gets easier. Now I believe I know what the problem, on the overlays line modify it to i2c0-pi and i2c1-pi. This appears to be a common problem with armbian-config overlay functional. My own A10 and A20 systems also has this problem as well.

Hi Yordan, Are you sure you have correctly enabled the i2c overlay on your board? what is the output of cat /boot/armbianEnv.txt? If something is showing up even with nothing apparently connected they your are likely targeting a different bus. It is possible what you are seeing is the address of the internal pmic although this normal shows up as UU. Best of luck Ryzer

A bit later than planned but finally got round to a system rebuild with 6.12.23 but still encounter the exact same issues as before. Loading a simple "hello_world" module intially appears to load successfully but if trying to removing it we then still get: ~/exp-drivers/hello_world$ sudo rmmod hello rmmod: ERROR: ../libkmod/libkmod-module.c:856 kmod_module_remove_module() could not remove 'hello': Resource temporarily unavailable rmmod: ERROR: could not remove module hello: Resource temporarily unavailable Attempting to call lsmod still spams a load of syslog messages and if we then try to call it again it just hangs. Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 403.890953] Internal error: Oops: 5 [#1] SMP THUMB2 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.312451] Process lsmod (pid: 1638, stack limit = 0x9d250a51) Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.325587] Stack: (0xf0dade00 to 0xf0dae000) Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.337169] de00: c16067b0 00000000 00000000 ffffffff c4103000 e2b03f90 6830fe88 e2b03f90 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.352658] de20: 00000400 c9854d70 00000000 bfa9e044 c9854d88 f0dadeb0 bfa9e044 c0309b0b Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.368148] de40: 00000000 00000000 f0dade98 c9854d98 00000001 c9f81000 2e9f8000 c9918300 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.383626] de60: c4043dc0 00000000 f0dadf80 c3126840 00000000 00000400 00000001 c0b217c4 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.399058] de80: c03522a5 c0309e59 00000400 00000001 01aafca0 00000400 00000001 00000000 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.414440] dea0: f0dade90 00000400 00000001 00000000 c3126840 00000000 00000000 00000000 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.429741] dec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000400 e2b03f90 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.445005] dee0: 00000400 c3126840 c9191400 01aafca0 f0dadf80 c02e61d5 00001a55 c4304068 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.460249] df00: c4304068 00000000 00000000 00000000 ffefe2c0 ef32c434 00000000 e2b03f90 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.475507] df20: b6e79fff f0dadfb0 01ab00a4 00000817 c9191400 00000255 c9918300 c0aca39f Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.490740] df40: 00000000 c0aca39f 00000000 00000000 00000000 e2b03f90 00000000 c3126840 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.506009] df60: c3126840 00000000 00000000 c01002a0 c9191400 00000003 00000000 c02e6a09 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.521213] df80: 00000000 00000000 c01002a0 e2b03f90 be93e100 01aae2e0 000005e8 b6bc5888 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.536430] dfa0: 00000003 c0100061 01aae2e0 000005e8 00000003 01aafca0 00000400 00000001 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.551603] dfc0: 01aae2e0 000005e8 b6bc5888 00000003 0000000a be93e3b4 00000000 00000000 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.566780] dfe0: 00000003 be93e2e0 b6b6037b b6ad9656 40070030 00000003 00000000 00000000 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.581942] Call trace: Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.581955] m_show from seq_read_iter+0xd3/0x37c Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.603084] seq_read_iter from seq_read+0xa5/0xcc Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.614746] seq_read from vfs_read+0x79/0x21c Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.626005] vfs_read from ksys_read+0x45/0x9c Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.637120] ksys_read from ret_fast_syscall+0x1/0x5c Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.648813] Exception stack(0xf0dadfa8 to 0xf0dadff0) Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.660406] dfa0: 01aae2e0 000005e8 00000003 01aafca0 00000400 00000001 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.67Segmentation fault Here is what lsmod looks like before trying to load a custom module and going haywire: Module Size Used by aes_arm_bs 20480 2 crypto_simd 12288 1 aes_arm_bs aes_arm 12288 3 aes_arm_bs ccm 16384 6 sunrpc 360448 1 rtl8xxxu 167936 0 mac80211 667648 1 rtl8xxxu axp20x_adc 16384 0 sun4i_gpadc_iio 12288 0 cfg80211 618496 2 mac80211,rtl8xxxu industrialio 61440 2 sun4i_gpadc_iio,axp20x_adc sun4i_ts 12288 0 rfkill 20480 3 cfg80211 libarc4 12288 1 mac80211 sunxi_cedrus 40960 0 v4l2_mem2mem 16384 1 sunxi_cedrus videobuf2_dma_contig 16384 1 sunxi_cedrus videobuf2_memops 16384 1 videobuf2_dma_contig videobuf2_v4l2 16384 2 sunxi_cedrus,v4l2_mem2mem videobuf2_common 45056 5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_memops,v4l2_mem2mem,videobuf2_v4l2 videodev 188416 3 sunxi_cedrus,v4l2_mem2mem,videobuf2_v4l2 mc 36864 5 sunxi_cedrus,videobuf2_common,videodev,v4l2_mem2mem,videobuf2_v4l2 cpufreq_dt 16384 0 evdev 16384 1 uio_pdrv_genirq 16384 0 uio 16384 1 uio_pdrv_genirq zram 24576 2 zsmalloc 16384 1 zram binfmt_misc 20480 1 dm_mod 98304 0 autofs4 36864 2 ext4 606208 2 mbcache 12288 1 ext4 jbd2 102400 1 ext4 pinctrl_axp209 12288 0 lima 49152 0 gpu_sched 36864 1 lima drm_shmem_helper 16384 1 lima sun4i_gpadc 12288 0 sunxi 12288 0 phy_generic 16384 2 sunxi display_connector 16384 0 gpio_keys 16384 0 uas 20480 0 icplus 12288 1 Maybe it would be a safer bet to build again with 6.6 for the time being or try with 6.14 and hope for the best?

Hi Lucas, In the /boot/armbianEnv.txt where you have the line "overlays=sun8i-h3-spi-spidev, you do not need the sun8i-h3 bit. I think it is a problem with how the current version of armbian-config adds overlays. Even though the actually name of the overlay would be sun8i-h3-spi-spidev.dtbo, the armbianEnv.txt only needs the interface name which in this case is spi-spidev. To the best of my knowledge there is no general spi-sunxi module, only spi-sun4i and spi-sun6i. The H3 is compatible with the spi-sun6i driver.

What SD card are you using? I don't believe the A20 is up to the task of running a modern desktop. It could still be a power issue if indeed no LEDs are on at all. Does the device turn off happen randomly or when the Banana Pi M1 power down when under high load? I'd advise getting a USB to Serial adapter to get a better idea of what is happening on the board. Best of luck Ryzer

Thanks for the update, I will create a fresh build this weekend. The only downside is that 6.6.x is now considered legacy. mue473, have you had a chance to test with the latest 6.12.x or higher for any module loading related issues? cheers Ryzer

Right will give it another go. Turns out adjusting the CMA is not straightforward in the case of the A10 or A20. The Video Engine can only access the first 256mb of memory, which is addressed via a DMA pool in the respective dtsi files. Anything higher than the default 96mb causes it become dissociated from the DMA pool. i suspect that's what lead to my earlier crashes.

Just to add if I try skipping forward it trips up and goes back to software decoding. Tried adjusting CMA buffers (128mb) but this just leads to the system crashing. [lavf] queuing seek to 243.633333 [lavf] execute seek (to 243.633333 flags 4) [lavf] seek done [file] stream level seek from 32352085 to 32875635 [vd] Pixel formats supported by decoder: vdpau vaapi drm_prime yuv420p [vd] Codec profile: Main (0x4d) [vd] Requesting pixfmt 'drm_prime' from decoder. [ffmpeg/video] h264: v4l2_request_try_format: pixelformat 842094158 not supported for type 1 [ffmpeg/video] h264: v4l2_request_buffer_alloc: create buffers failed for type 1, Cannot allocate memory (12) [ffmpeg/video] h264: Failed setup for format drm_prime: hwaccel initialisation returned error. [vd] Pixel formats supported by decoder: vdpau vaapi yuv420p yuv420p [vd] Codec profile: Main (0x4d) [vd] Requesting pixfmt 'yuv420p' from decoder. [statusline] (Paused) V: 00:04:03 / 01:24:45 (5%) [osd/libass] libass API version: 0x1701000 [osd/libass] libass source: tarball: 0.17.1 [vd] Falling back to software decoding. [vd] Detected 2 logical cores.

Hi @Nick A The problem appears to be at my end, anyway managed to download the ffmpeg-vl42-request debs in the end and will be testing shortly. Thanks for the patches, I only had a slight hiccup when trying to integrate 2 of them. I found that patch 556 no longer appears to be necessary as those changes already appear to be implemented within my current Armbian build fork. The A10 and A20 use the Mali 400 so I have also borrowed patch 125. Good to here the CMA no longer need to be adjusted. Latest build has completed successfully. MPV is using ffmpeg-request. Now it seems to use hardware decoding. That is the good news at least. The bad news is that it is an incomprehensive grid of sqaures. At the beginning I still get this line: [vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device. Thanks Ryzer

Hi Nick, Thanks for the suggestion, after doing a bit more research it does seem like v4l2-request is better suited. I did attempt following jocks instructions but I could not add the apt repo as it yielded a network unreachable error. AS a work around I will try with Kwiboo's instead: https://github.com/Kwiboo/FFmpeg as this also has v4l2-request support. Thanks for providing the patches, I am interested to see how they will preform on the A10, I will be sure to implement them next time I get round to a system build. Once I get a positive indication that hardware acceleration is working I will trying increasing the CMA size but I may need to change screens. My current system only has a cma of 96MB, in the past I found if I set it too high it will stop displaying at all on my 4K monitor. @jwalds I dont believe so, I have yet to find a patch that adds encoding to the cedrus driver. A possible start point would be here: https://github.com/bootlin/linux/tree/cedrus/h264-encoding as it looks like some work has at least started. just to add testing with MPV did not exactly yield great results, the image seems to bounce up and down for a few seconds then freezes as the system appears to crash Thanks Ryzer

Hi Jwalds, Looking back I just realised that you are still using kernel-6.1, which is now considered "legacy" and no longer as actively supported. You are likely to have better chance of success with an image built around at least kernel 6.6 which has a more developed version of the cedrus driver. To clarify a further more the cedrus driver is exposed via the v4l framework so this is what ffmpeg has to be built with support for. Now I managed to successful build ffmpeg on my own board, a Pcduino2 (A10) which admittedly is much older than H616 but shares the same cedrus driver and some of the same codecs. In my case I found that ffmpeg failed when attempting hardware decoding. Looking into the debug output, ffmpeg was detecting the cedrus driver but apparently running into somekind of formatting issue. I don't know of it is caused by the demo clip I was using or an underlying issue in the driver. best of luck Ryzer

Hi All, Good to hear that the cedrus driver appears to be initialized correctly. It has been a while since I last tried hardware accelerated playback and unfortunately did not have much success. From what I remember from another topic is that in order to utilize the cedrus, ffmpeg has to be compiled with v4l2m2m (--enable-v4l2-m2m) support in place. From what I can tell this is not set in the system packaged version of ffmpeg. Hope this helps Ryzer