langweiler

I am trying to enable the external antenna on my Radxa Zero SBC. I was assuming that there is a kernel overlay available to achieve this, but unfortunately not. At least I am unable to find it using armbian-config. I am running Armbian v24.11.1 with kernel 6.6.63-current-meson64. Has anyone ever achieved to enable the external antenna? Any hints appreciated.

Hi Igor, Thanks for your comprehensive reply. As written before, I did not mean to accuse the Armbian developer team in any way. I am only a private end user. I am tinkering around with SBCs and run Armbian on two devices. I can donate a few Euros (and just did). Unfortunately, that is not going to change the situation. You probably need 100 times the amount I donated to implement hardware accelerated video decoding realiably - at least if done by a professional. I am not sure if I understand the Armbian business model. In my view, the only model that will work reliably is if the cost for software development is factored into the price for the hardware. When I buy a device from Radxa, I expect the proper software to come with it. If Radxa is not able to provide the necessary software, they should pay someone else to do so. That is why I wrote "I hope someone from Radxa is reading this." in my previous post. This would also take the pressure from new hardware coming out. New hardware would mean new revenues for everyone. In general, new hardware should only be launched after reasonably stable software can be provided with it. At the moment, I buy hardware from Radxa with great features, which I am not able to use. And those deficits are not clearly stated on their web page. This is where my frustration comes from. It has nothing to do with Armbian at all.

Thanks for pointing me to the other thread. I have to admit that I am quite disappointed. The summary of the situation by chewitt was already posted in Aug 2021. And still hardware accelerated video decoding is broken at least on the Radxa Zero device albeit it seemed to have been working for some time and the hardware has been around for ages (that is at least my impression). This is no by no means an accusation and I very much love the work done by Armbian developers. I am more frustrated about the marketing by companies like Radxa who advertise the impressive capabilities of their SBCs, but do not ensure the necessary driver support. What is the point of having powerful hardware (and having to pay the price for it) if in the end software support is not mature and you cannot benefit from it? Hopefully, somebody from Radxa is reading this. There is room for improvement! Be outstanding and deliver the best hardware *and* software combination available on the market! I am willing to pay for it!

I am running the Ubuntu Noble 24.04 XFCE image on a Radxa Zero SBC (first generation device). Trying to play a video with parole (gstreamer video player) produces the error message "GStreamer Backend Error: Could not read from resource. " Increasing the gstreamer debug level produces the following additional information: 0:00:00.329008719 131342 0xaaab079354e0 WARN GST_ELEMENT_FACTORY gstelementfactory.c:765:gst_element_factory_make_valist: no such element factory "autoimagesink"! 0:00:05.702394971 131342 0xffff7c0013d0 ERROR v4l2bufferpool gstv4l2bufferpool.c:716:gst_v4l2_buffer_pool_streamon:<v4l2h264dec0:pool0:sink> error with STREAMON 22 (Invalid argument) 0:00:05.702572595 131342 0xffff7c0013d0 ERROR v4l2bufferpool gstv4l2bufferpool.c:2233:gst_v4l2_buffer_pool_process:<v4l2h264dec0:pool0:sink> failed to start streaming 0:00:05.703109216 131342 0xffff7c000da0 WARN v4l2 gstv4l2object.c:5887:gst_v4l2_object_poll:<v4l2h264dec0> error: poll error 1: Connection timed out (110) 0:00:05.703217049 131342 0xffff7c0011a0 WARN qtdemux qtdemux.c:7423:gst_qtdemux_loop:<qtdemux0> error: Internal data stream error. 0:00:05.703483881 131342 0xffff7c0011a0 WARN qtdemux qtdemux.c:7423:gst_qtdemux_loop:<qtdemux0> error: streaming stopped, reason error (-5) Looks like there is an issue with the v4l device provided by the meson_vdec kernel module. Removing the meson_vdec kernel module indeed eliminates problem. Videos are played without error message using software decoding. The frame rate is unfortunately low. Otherwise I would not care about hardware decoding. Interestingly, the v4l2-compliance command suggests that the v4l device for the VPU is in good shape: $ v4l2-compliance v4l2-compliance 1.26.1, 64 bits, 64-bit time_t Compliance test for meson-vdec device /dev/video0: Driver Info: Driver name : meson-vdec Card type : Amlogic Video Decoder Bus info : platform:meson-vdec Driver version : 6.6.31 Capabilities : 0x84204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Detected Stateful Decoder Required ioctls: test VIDIOC_QUERYCAP: OK test invalid ioctls: OK Allow for multiple opens: test second /dev/video0 open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK test for unlimited opens: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 0 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK test VIDIOC_QUERYCTRL: OK test VIDIOC_G/S_CTRL: OK test VIDIOC_G/S/TRY_EXT_CTRLS: OK test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 2 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test CREATE_BUFS maximum buffers: OK test VIDIOC_EXPBUF: OK test Requests: OK (Not Supported) Total for meson-vdec device /dev/video0: 46, Succeeded: 46, Failed: 0, Warnings: 0 What is the current status of meson VPU support? Is this a known issue? Has anyone ever got video hardware decoding to work with the Radxa Zero SBC? Thanks for any hint in advance! armbianmonitor.txt