usual user

Sorry, I don't know at what "mainline" gstreamer you are. I can't see a line 134 in gstv4l2codec.c nor has gstreamer a subprojects/FFmpeg.

That report doesn't look that bad. If the decoder is exported correctly, i.e. it is correctly described in the DTB and the driver has been loaded automatically, you only need a corresponding video framework that uses it. Depending on the application you plan to use, this is either ffmpeg or gstreamer. For ffmpeg you need one with a properly patched in request-api. For gstreamer, it is sufficient to use a current mainline release with these built elements: gst-inspect-1.0 | grep v4l2 v4l2codecs: v4l2slh264dec: V4L2 Stateless H.264 Video Decoder v4l2codecs: v4l2slmpeg2dec: V4L2 Stateless Mpeg2 Video Decoder v4l2codecs: v4l2slvp8alphadecodebin: VP8 Alpha Decoder v4l2codecs: v4l2slvp8dec: V4L2 Stateless VP8 Video Decoder gst-play-1.0 --use-playbin3 bbb_sunflower_1080p_60fps_normal.mp4 will assemble a video pipeline that uses the hardware decoder out-of-the-box. mpv --hwdec=auto --hwdec-codecs=all bbb_sunflower_1080p_60fps_normal.mp4 will use it via "hwdec: drm" if a proper patched ffmpeg framework is available. See mpv.log for reference.

To check if the kernel exposes a suitable decoder run a script like this: #!/bin/bash for I in {0..12} ; do printf "################################################################################\n\n" v4l2-compliance --device=/dev/video${I} EXITSTATUS="${?}" [ "${EXITSTATUS}" == "0" ] || printf "Compliance test for device /dev/video${I} failed, exitstatus: ${EXITSTATUS}\n" printf "\n" done You need v4l2-compliance from the v4l-utils-tools.

When the request-api is patched in properly, you are looking for: ffmpeg -hide_banner -decoders | grep v4l2 V..... h263_v4l2m2m V4L2 mem2mem H.263 decoder wrapper (codec h263) V..... h264_v4l2m2m V4L2 mem2mem H.264 decoder wrapper (codec h264) V..... hevc_v4l2m2m V4L2 mem2mem HEVC decoder wrapper (codec hevc) V..... mpeg1_v4l2m2m V4L2 mem2mem MPEG1 decoder wrapper (codec mpeg1video) V..... mpeg2_v4l2m2m V4L2 mem2mem MPEG2 decoder wrapper (codec mpeg2video) V..... mpeg4_v4l2m2m V4L2 mem2mem MPEG4 decoder wrapper (codec mpeg4) V..... vc1_v4l2m2m V4L2 mem2mem VC1 decoder wrapper (codec vc1) V..... vp8_v4l2m2m V4L2 mem2mem VP8 decoder wrapper (codec vp8) V..... vp9_v4l2m2m V4L2 mem2mem VP9 decoder wrapper (codec vp9) ffmpeg -hide_banner -hwaccels Hardware acceleration methods: vdpau cuda vaapi drm opencl vulkan And mpv (shift i) will use it via the drm hwaccel: Either your used gstreamer version is too old to have out-of-the-box support at all, or the build of a current mainline version has not activated the necessary components.

While exploring my Info Center, I stumbled across this screen: If there are other users who use a Samsung SSD 980 PRO 2TB, they may also be interested in following this link: https://www.pugetsystems.com/support/guides/critical-samsung-ssd-firmware-update/

They are floating around. Some of them are in flight to land in mainline, some are WIP in heavy flux. In terms of functionality, mainline would not be able to do more than legacy so far. And since your offered legacy firmware works so far, there is currently no reason to do the work now to use the current mainline version. It is only interesting for someone who wants to add e.g. VOP2 or NVME driver support and ports the drivers from Linux kernel. For all pure users it is easier to wait until all outstanding components have landed and then just use mainline. Anyway, my SPEC file for the uboot-tools package is now ready to build M1 firmware as soon as needed. However, this will certainly take until 2023.07 at the earliest, because there are still some components under discussion and 2023.04 should be available next week.

Since @Igor don't like my source of knowledge, I'll leave it to him to answer such Armbian user queries now, because in his opinion sharing knowledge and having mainline support doesn't seem to be of any help to Armbian 😉

My first u-boot build:

Sure, with distro-boot only a suitable firmware in the firmware area and three files in a partition accessible from the firmware is required. Because I still have Petitboot in SPI flash, I used @rpardini's initial image as boot trampoline, because Petitboot requires a very special partition layout. Then the kernel binary, the DTB and extlinux.conf copied into the partition, and my operating system is entirely run by the NVME. It should be noted that the kernel binary must be uncompressed, as the legacy firmware does not even support compressed kernel binaries. I use a microSD card as boot trampoline, because the firmware only reads it, and I only mount it from the operating system read-write if I want to update the kernel binary or the DTB. But an eMMC works the same way. The only annoying thing about this method is the need to copy the kernel binary and DTB over, but this is a simple workaround until mainline firmware is available.

Thank you for collecting the diverse logs. Unfortunately, they only confirm my initial analysis. The issue occurs when the NVME initialization should take place. The first part of the PCI client initialization succeeds: [ 2.216527] pci 0000:00:00.0: [1d87:0100] type 01 class 0x060400 [ 2.217239] pci 0000:00:00.0: supports D1 [ 2.217613] pci 0000:00:00.0: PME# supported from D0 D1 D3hot [ 2.221587] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring while the next one: [ 2.222558] pci 0000:01:00.0: [1e4b:1202] type 00 class 0x010802 [ 2.223199] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit] [ 2.223977] pci 0000:01:00.0: Max Payload Size set to 256 (was 128, max 512) [ 2.225062] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold [ 2.226049] pci 0000:01:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:00:00.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link) triggers the issue in the event of an error. The cause remains unclear, but since two autonomous devices interact via a complex PCI protocol, further analysis can be very time-consuming. In any case, this requires a kernel developer who is familiar with the PCIe subsystem. It is known that not all conceivable hardware combinations will work, so other SBC manufacturers collect test reports to give their customers a guide which combinations can be used. This is the economically most favorable way to get a functioning system, development costs are usually way higher than the purchase of a suitable NVME SSD. But this is only a workaround solution. The fact that the error situation seems to depend on the runtime behavior does not make fixing any easier. In this case, a completely different cause may also be responsible. From the logs it can also be seen that even the firmware does not recognize the SPI flash on a case-by-case basis: Loading Environment from SPIFlash... jedec_spi_nor flash@0: unrecognized JEDEC id bytes: ff, ff, ff *** Warning - spi_flash_probe_bus_cs() failed, using default environment

To analyze this further, I need a detailed serial console log. Please select the "linux verbose" boot option by entering a "3" on the serial console while the boot options are displayed and the countdown runs. I also see that a different firmware is used and I don't know where it is loaded from as it is not the one included in the Armbian image. To identify the firmware as the culprit for the PCIe problem, it would be interesting to also see a log with the boot option "5.15.80-rockchip64" (4).

Here my final analysis. A kernel built with a completely different toolchain than Armbian's is now used. The kernel configuration varies in many respects from those of Armbian. My build is based on pure mainline sources where only these patches were applied, but these have no relevance for PCIe support. The test with my build has ruled out a shortcomming of Armbian due to their toolchain, configuration and applied patches. The difference between my rk3399 device and yours is the specific hardware and how it is wired via DTB. Since the PCIe support works for me, it can be assumed that the issue is triggered by your special hardware constellation. This suggests that a shortcomming exists in the kernel code. To analyze the problem further, someone familiar with the kernel PCIe code is now needed, but I doubt if anyone is available for free. There would have been a small chance for the DTB configuration as the cause, but since you preferred not to provide me with the full serial console log, I can not confirm this.

I don't expect you to switch to fedora, but every Linux user should be able to execute basic cli commands to copy a kernel into position. In this way, we can at least determine whether it is just a configuration issue or whether a bugfix is really needed. At the very least, you meet the necessary requirements, an affected device, and serial console access to investigate the issue further. I added my kernel build to the Armbian image for you and uploaded it here. Because I do not have an identical to your device to test, I can not guarantee that the result works at all. So download it and post the serial console log while it boots.

I run fedora as userspace but although fedora offers all mainline components available for the RockPi 4B, there is no out-of-the-box image. You need to know what is necessary to configure the system and how to set it up. Also, you have to add components that are not available in mainline yourself, such as firmware where the manufacturers think it is a good idea to formulate the distribution licenses in such a way that free software may not ship them out-of-the-box. The user space software components work fine, provided the kernel has the necessary mainline driver support. Out-of-mainline components like Wifi calibration parameter files must be added by yourself, i.e. YMMV. I'm sure my configured microSD card would work out-of-the-box for your device also, but the only thing I can offer is my kernel build, which is then integrated into the Armbian image of your choice to find out if it works for you.

The supplied logs prove that the kernel causes a "synchronous external abort" when the pcie sybsystem is initializing. The fact that both logs look similar is because both images use the same kernel and user space doesn't even come into play when the issue occurs. Since a rather old kernel is used, I would first switch to a more recent one to further identify the issue. With my rk3399 device I have been using NVME flawless for a long time. I therefore assume that there is no fundamental code problem. However, I am currently running 6.1.0, which contains improvements that were certainly not back-ported to 5.15.80. The rk3399 mainline kernel support is very advanced, so it doesn't make much sense to waste time analyzing a behaved kernel. Maybe the issue no longer exists with a kernel upgrade and that's all that's necessary.

TF-A is progressing slowly, but there seem to be still open questions. The DT rebase of u-boot has taken place. It still takes a rebase to be up to date, but this is only a small thing, because the basic structure conversion has already taken place. But I haven't seen any movement in uboot WIP trees that I'm aware of. IMHO they are waiting to see how the TF-A development turns out in the end to develop u-boot accordingly further. I will report when I get news. But the most important thing is that for the kernel only the rkvdec2 support is missing, and for the userspace only the FFmpeg v4l2-request support is missing to be usable out-of-the-box with pure mainline support for standard applications. It is thus available for all distributions without special effort for the Odroid-M1. They only have to maintain the distribution-specific modifications that they apply for other devices anyway. I'm currently playing with jernej's FFmpeg patches for v4l2-request support and VP8 acceleration seems to work. H.264 fails with this error: [h264_v4l2m2m @ 0xaaaabfc5ae10] Could not find a valid device [h264_v4l2m2m @ 0xaaaabfc5ae10] can't configure decoder But I don't know if the 5.1.2 paches basically work or how I can inspect the FFmpeg framework appropriately. With the gstreamer framework, however, everything works as expected.

Odroid-M1 support has just landed so will be available with 6.2.0-rc1 out-of-the-box. RGA support can be wired on top (v4l2-compliance.log), but the DMA deficiency for 32-bit addresses needs to be addressed for devices with more than 4GB of RAM.

For out-of-the-box mainline kernel support you need at least 6.1.0-rc1 because that's where all currently available code for the rk3568 SOC has landed. GPU support has been available for a long time, see glmark2-wayland-odroid-m1.log for reference. And Mali-G52 is official conformant for OpenGL ES 3.1. VPU support is only available for the hantro IP. So hardware-accelerated video decoding of H.264 and VP8 works up to 1080p. See fluster-run-odroid-m1.log for reference. The available drivers are in quite good shape, see v4l2-compliance.log for reference. The support for the rkvdec2 IP is not yet available, so no 4K resolution and no VP9 and HEVC hardware decoding for now. Hardware encoding is only available for JPEG in poor quality. But missing mainline encoder support applies almost for all SOCs. If you need 4K resolution, VP9 or HEVC codecs, you have to currently rely on the vendor's legacy kernel with proprietary interfaces.