The way the netplan + networkd integration is designed requires all the network devices (wlan0 in particular) to exist at /sbin/init time - otherwise, the netplan generator disables `systemd-networkd-wait-online.service` which also causes `network-online.target` to be reached early. In particular, this breaks any network FS mounts on boot.

Of note, I tried logging in to file the bug via the dev contribution platform, but it looks I'm blocked from JIRA access, so am filing it here instead.

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

radxa_zero_serial.log

I installed armbian_23.8.1_Radxa-zero_bookworm-current_6.1.50 on Radxa Pi Zero eMMC and I have an USB SSD drive connected as storage. Everything worked fine using it as a NAS but if I reboot there is an endless loop of reboots with the core message "scanning bus usb0ff5000000 for devices... Synchronous Abort handler, err 0x56000010". If I disconnect the USB drive it boots fine and when reconnect it after the boot process, the drive works fine. But I really need a system that is able to boot without temporarely disconnecting USB. I tried different combinations of USB with two different hubs or without hub. There are no boot flags on the partitions. I completely deleted all partitions on the drive and tried different kind of partitions and file systems. It does not change anything. Even without any partition it has the same error. I have another USB SSD that also causes a few pages of error messages but after that it does boot (from eMMC). Unfortunately that is the wrong USB drive and does not help. Switching too the newest kernel with armbian-setup also does not work.

Finally I installed Radxa Ubuntu 20 and it boots without any issues while the USB SSD is connected. What can I do to solve this when using Armbian?

Thanks

Tobi

https://paste.armbian.com/cirulemeho

I found two i2c devices, 3 and 5.
 

sudo i2cdetect -y -r 3
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- UU -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

sudo i2cdetect -y -r 5
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

I think the 5 is for HDMI, right?
Would the UU for the 3 mean my screen is not correctly connected or detected?

Thanks.

I'm running Armbian 23.11.1 Bookworm 6.1.63 64-bit.

When I run v4l2-ctl -i /dev/video1 --list-formats to query the webcam, it errors out.

VIDIOC_S_INPUT: failed: Inappropriate ioctl for device
ioctl: VIDIOC_ENUM_FMT
        Type: Video Capture Multiplanar

        [0]: 'NM12' (Y/UV 4:2:0 (N-C))

It seems anything relying on v4l2 is also failing to work.

Anyone have ideas of what the issue may be?

Thanks!

----------------------

FYI...If I use this webcam on a RaspberryPi 4 running Bookworm, it produces the following output and all v4l2 work.

Video input set to 0 (Input 1: Camera, ok)
ioctl: VIDIOC_ENUM_FMT
        Type: Video Capture

        [0]: 'YUYV' (YUYV 4:2:2)
        [1]: 'H264' (H.264, compressed)
        [2]: 'MJPG' (Motion-JPEG, compressed)

Why do you list Armbian 23.5 Jammy as a supported load on https://www.armbian.com/radxa-zero/

Armbian 23.5 Jammy works on the 2G version of the Radxa Zero board.

Armbian 23.5 Jammy does NOT work on 1G version of Radxa Zero. (and presume the .5G version)

  - Boot failure loop after identifying boot device on 1G version of Radxa Zero.

Has this been fixed? In which version? Where do we find it?

Armbian_22.08.0-trunk_Radxa-zero_bullseye_current_5.10.134_minimal.img.xz works on 1G version of Radxa Zero.

   - https://github.com/radxa-build/radxa-zero/releases/tag/20220801-0213

Like the title says the UART overlays are not working on the armbian radxa zero device if I use the official out-of-the-box image. 

Using the armbian-config I can enable UART A and B but these changes do not reflect in the /dev/tty devices (using other distros is can see /dev/ttyAML0, /dev/ttyAML1 and /dev/ttyAML4). Unless the devices are called something else i confirm that the overlays are not working. 

That being said I want to recompile a armbian image with the correct overlays but I am a complete noob. 

Here is my plan : 

i successfully compiled a minimal cli armbian image for the radxa zero without any modification (whooohoo)

i found the overlays from the official radxa github (whooohoo) : https://github.com/radxa/overlays/blob/main/arch/arm64/boot/dts/amlogic/overlays/README.overlays

Now i want to include these overlays in the armbian project so that they can be compiled in the image.

Reading the documentation i think that i need to include these files somewhere in the package directory:

or somewhere in the config directory

I also think I need to include some compiling instructions. 

I feel like I'm so close but at the same time, I feel like I'm so far. 

Any direction is very much appreciated.

Thank you

ps the board is officially supported but I can't find the appropriate topic.

After booting, I connected my device to the UART port, it worked well through /dev/ttyAML0.

Any suggestions? Many thanks!

I tried all different Armbian debian versions, lsmod never give me module cec

So I took a look at images provided by radxa (https://github.com/radxa-build/radxa-zero/releases/tag/20220801-0213, not armbian ones), cec is loaded by default

I think this is the key:

/lib/modules/SOME_KERNEL/kernel/drivers/media/cec/core/cec.ko

This is in their image but not /lib/modules/6.1.11-meson64 folder (I guess also not in other kernel versions)

If that's the case, CEC should not work on any meson64 devices.

I saw CONFIG_CEC_CORE=y is in config. 

btw, another possible related missing module is meson_dw_hdmi.ko

Could someone take a look and figure out why they are not there?

Really appreciate your help!

Thanks

Armbian_22.05.0-trunk_Radxa-zero_bullseye_current_5.10.113_minimal - doesn't boot

radxa-zero-ubuntu-focal-server-arm64-20220501-0334-mbr - boots but just goes straight into login screen, no option to change password. root and 1234 do not work. Also no armbian_first_run.txt.template included in the image

Armbian_22.02.3_Radxa-zero_jammy_edge_5.15.32_xfce_desktop - doesn't boot

Armbian_22.02.3_Radxa-zero_focal_current_5.10.109_cinnamon_desktop - doesn't boot

Armbian_22.02.3_Radxa-zero_bullseye_current_5.10.109 - doesn't boot

Armbian_22.02.3_Radxa-zero_focal_current_5.10.109_xfce_desktop - doesn't boot

Armbian_22.02.3_Radxa-zero_jammy_edge_5.15.32 - doesn't boot

I have a couple of zeros so I went back and forth between the two testing the images. Used DD and Gnome Disks, neither had any luck. Currently running DietPi which seems to be doing well. CoreElec runs good too.

However, after booting, the device /dev/ttyAML4 does not appear.

The download log contains the following information:

Using the kernel-provided DT meson-uartC.dtbo overlay
fdt_overlay_apply() error: FDT_ERR_BADMAGIC
base fdt has no node /__symbols__
make sure you compile with -@

Error applying DT overlays, restoring original DT

I would be grateful for any help!

/dts-v1/;
/plugin/;
/ {
	compatible = "radxa,zero", "amlogic,g12a";
	fragment@0 {
		target = <&usb>;
		__overlay__ {
			dr_mode = "otg";
		};
	};
};

I can open a PR for adding this as device tree overlay, or enabling OTG OOTB on Radxa Zero, like vendor did: https://github.com/radxa/kernel/commit/775a467

The latter would be simple. In case of an overlay, I'd need some hint about how to do it best:

• Adding it to the general meson64 overlays patch seems to be right: https://github.com/armbian/build/blob/master/patch/kernel/archive/meson64-6.0/general-meson64-overlays.patch
• But how to prefix or set `compatible` attribute best to assure it can be applied, resp. make clear that it works on Radxa Zero only (as state of testing)?