usual user

Usually I use armbian barely. So I can't really say anything about the nature of hers implementation. It's probably up to the user's decision. In terms of file name, it could follow a similar scheme to how I use it. Since the use of NOR flash has an influence on the usable eMMC speed, armbian probably also offers a variant with and without its support. I also use the DTB filename to express which features I've added. E.g. one of my DTB is: meson-g12b-odroid-n2-plus-con1-opp-uart.dtb with multiple overlays applied. This way I just need to replace the original DTB with the desired one, this works in any environment regardless of an overlay framework.

ffmpeg -hide_banner -decoders | grep request returns for me ... NOTHING also, but hwdec is working as expected. So your statement seems not to be correct. From "man mpv": NOTE: Even if enabled, hardware decoding is still only white-listed for some codecs. See --hwdec-codecs to enable hardware decoding in more cases. Which method to choose? If you only want to enable hardware decoding at runtime, don't set the parameter, or put hwdec=no into your mpv.conf (relevant on distros which force-enable it by default, such as on Ubuntu). Use the Ctrl+h default binding to enable it at runtime. If you're not sure, but want hardware decoding always enabled by default, put hwdec=auto-safe into your mpv.conf, and acknowledge that this may cause problems. If you want to test available hardware decoding methods, pass --hwdec=auto --hwdec-codecs=all and look at the terminal output. As the hacked in request-api codecs are not white-listed in mpv proper by default ==> so "--hwdec=auto --hwdec-codecs=all"

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml

The patch set should be applied to the source for which it was designed, even if it can be applied cleanly to another source, there is no guarantee that a change in a non-contradictory place will not affect functionality. The specific ffmpeg version is not decisive here, since the request-api can be patched in for quite some time, e.g. I am currently still using a 5.x for other reasons. So if you've cloned the ffmpeg git repository, it's just a "git checkout <commit>" away to have a corresponding version. I grabbed the patches from @jernej's Github at the time, as his branch names indicate which version they belong to. Of course, the 5.x ones are long gone.

@Kwiboo did a fantastic job. Mainline u-boot becomes usable (console.log) for me. It enumerates my different systems on different storage media and can natively load the boot components from them. The use of compressed kernels does not work yet, it bails out like this: The u-boot control still has to be done with the serial console, as HDMI support is still missing, but it is still an early stage and the development is vivid. In the meantime, I have solved the problem with loading compressed kernels for me. Also, I can now use a USB keyboard (usbkbd) for stdin. Both require a correction of the mainline code, but since unfortunately too many in-flight patches have not yet landed, it is still too early to go into detail here. If you already want to play with the functionality that will be provided by the mainline u-boot in the future out-of-the-box, I have uploaded my firmware build here. The firmware can be put in place by: dd bs=512 seek=64 conv=notrunc,fsync if=u-boot-rockchip.bin of=/dev/${entire-device-to-be-used} into the firmware area of an SD card or an eMMC. If it is started during power-up by holding the SPI recovery button (RCY), it will scan all connected storage media for a usable bootflow. Supported boot methodes are: extlinux (extlinux.conf), efiboot and legacy-boot (boot.scr). As soon as video support is available, "U-Boot Standard Boot" will be fully usable, but VOB2 support is still open.

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.