usual user

In the root of the uboot source tree run: make rock-pi-4-rk3399_defconfig Save a copy of the .config file for later comparison. Then run: make menuconfig After exiting with Save, compare the current .config with the saved default .config.

Modifing /configs/rock-pi-4-rk3399_defconfig is a brute force method without paying attention to restrictions and dependencies. You have to know what you are doing. Usually I run "make menuconfig" to make changes, then I compare previous and new .config to learn necessary option changes, which I then add in *_defconfig for easy package building.

wrong way to disable Kconfig option use: # CONFIG_DEBUG_UART is not set see for reference: # CONFIG_ANDROID_BOOT_IMAGE is not set

Mainline kernel has fairly compliant decoder support for rk3399, see fluster-run-nanopc-t4.log for reference. Only this patch set is yet missing for HEVC decoder support. Current gstreamer framework provides out-of-the-box support, FFMPEG framework still requires several pending patches that need to be applied for v4l2-request support.

The kernel has support for it and my rk3399 device makes use of it: Why it isn't wired up for Helios64 I can't tell, but when my kernel is running it can be wired up and tested.

If it's just about a current mainline kernel build, I might be able to offer my build. I know from the experiment in this thread, that my kernel builds are working for Helios64. It is possible to keep as many different kernels installed as persistent space is available. A kernel upgrade will never leave an unbootable system behind as long as a previously working one is still installed. So if someone wants to experiment with my kernels, you have to let me know and I will talk you thru the experiment.

Ok, I went on to 6.0.0-rc1. A big pile of in-fligth commits have landed and only a few WIP commits are left over: They are basically general improvements to dw_hdmi and phy support for PCIe v3 with the rk3568 that are still in the works. The rest is devietree related and I hope it lands soon, because then everyone has out-of-the-box support with a pure mainline build. NVME gives nice tranfer rates: With a single job fluster run the H.264 score increases also, see fluster-run-odroid-m1.log for reference.

cat /sys/class/leds/n2:blue/trigger should list all available triggers for the LED, and echo mmc0 > /sys/class/leds/n2:blue/trigger should enable it as an HDD LED for the SD card. That was to be expected, because with it you have reactivated the legacy boot method, which of course has no idea how to boot my kernel and boots the stock Armbian kernel. This was just a hint, if a working Armbian kernel were available again, to switch back and forth between my additions and the Armbian method comfortably. I could also have added an option to offer the Armbian kernel with distro-boot as well, but since the kernel has been proven not to work, I left it out. Distro-boot can use as many kernels installed at the same time as the SD card space allows. Very convenient to quickly switch between multiple versions to compare. Like you just did to find out that it doesn't work even with an already configured userspace .😉

This is now the part where the real work begins. My kernel proves that a solution exists and does not have to be developed first. If the solution to the issue came from the further development to my kernel version, it is sufficient to bring Armbian to at least this version. If the solution to the issue is due to a configuration of the kernel build and Armbian does not have it, it must be identified and possibly also applied in Armbian. I don't think it's because of patches I add, because as far as I see they are not relevant to the issue. If you have developed a solution that works with the Armbian build system, you need to read the Armbian documentation on how to add your work via a pull request to Armbian. I can still give some basic hints if needed, but I don't have the necessary interest in Armbian to want to do all this work. Maybe you can attract an Armbin maintainer to help with this.

Congratulations, you have successfully proven that the stock Armbian kernel is the culprit of your issue. Here is a small summary of what we have achieved so far. You have changed your boot method to distro-boot. You successfully run a fedora kernel in an Armbian environment. Your image is now suitable for several devices, e.g. N2+, M1, NanoPC-T4, Helios64, ... Only the append line in the extlinux.conf has to be adjusted accordingly, because the SOCs require different kernel configurations. The boot method is quite fail-save and it takes some effort to create an unbootable system. The ledtrig heartbeat driver is built as a module and is not loaded automatically. This command should return your heartbeat: modprobe ledtrig-heartbeat Usually I configure it as an HDD LED for the SD card. Depends on what your intention is. You can insert my kernel into any image with mainline kernel this way. Legacy out-of-tree kernel images can also be booted, but userspace will lack legacy out-of-tree functionality that the kernel does not provide. In this way you could follow my kernel builds and request updates if necessary. You can wait until Armbian catches up with my kernel version and hope that your issue is fixed. To switch back to the legacy boot method, move extlinux.conf out of the way. E.g.: mv extlinux.conf extlinux.conf-disable You start with further investigations to identify the cause in the Armbian kernel build. Then prepare an pull request to get it integrated in Armbian. This is the fastest way to return to the stock Armbian system.

I have prepared an extlinux.conf. Mount the Armbian SD card partition and create an /extlinux directory in the root filesystem of the Armbian SD card. Then copy the attached extlinux.conf in. Download this kernel package and unpack it with this command in your Armbian SD card /usr/lib/modules/ branch: tar -C ${mountpiont}/usr/lib/modules/ -xzf 5.19.0-0.rc6.46.fc34.aarch64.tgz Boot with the SD card and report if this changes anything.

Looks like the firmware is not the culprit. Seems the kernel has some problem. We can install a newer one to prove this. For this I need the PARTUUID of the corresponding image for preparation. To get this, connect the Armbian SD card as if to run the dd commands, and then post the output of: lsblk --output +PARTUUID

This is because anyone can upload files there and no one checks their content. This is because it only contains the firmware that you should replace in your Armbian image. To do this, you must first install your desired Armbian image to the SD card and then replace the firmware component with the given command. The screenshots indicate that you haven't previously installed an Armbian image.

Only a shot in the dark. Download this firmware and extract it with: tar -xzf u-boot-meson.tgz Write it to your with Armbian prepared SD card: dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/${entire-card-device-to-be-used} Boot with this SD card and report if this changes anything.

I think I have to disappoint you, see here.

So another reason why it doesn't hurt if RKVDEC HEVC only lands in 5.20.0. What is it good for if you can decode a video but can't see the result? What I miss is where rk3399 DRM KMS development is taking place, all current media improvements have been promoted mainly by developments for other SOCs. I do not expect DRM KMS development to be a duty of LE developers.

If it doesn't land, it's not a show stopper. Adding this patch is a trifle. What I fear more is the availability of the necessary rebase of the LE patches: linux-0011-v4l2-from-list.patch linux-0020-drm-from-list.patch linux-1000-drm-rockchip.patch linux-1001-v4l2-rockchip.patch linux-2001-v4l2-wip-iep-driver.patch because I think some of it is still needed so that the VOP can also process all new output of the decoder.

Went on to 5.19.0-rc6 with all in flight work on top. With all this in place I for the first time can confirm the HEVC decoder is working for me. \o/ See fluster-run.log for reference.

I have nothing to decide here, if you want it to be in Armbian you have to convince an Armbian maintainer to pick it up. I also use Armbian only very sporadically for board bring-up and initial tests. Nevertheless, when the release has taken place, I will build a uboot-tools package for me and can, if you wish, upload the firmware. I use it to start my system from SD card or via USB connection. I don't see any reason why it shouldn't work with eMMC, but you only know for sure if you've tested it. For me it was the first action to replace Petitboot with a mainline uboot. You have to wait a little longer, see here. Release v2022.07 has taken place and the uboot-tools package has been build. I am running the firmware from SPI flash and it is working flawless for me. Since distro-boot is supported for free, the use of an extlinux.conf allows to select the current kernel, an previous one and a persistent one with the option to enable SPI flash for ODROID-N2 or ODROID-N2+. See the attached extlinux.conf as an example implementation. More details can be extracted from this thread, with its distracting posts in between. It is possible to keep as many different kernels installed as persistent space is available. A kernel upgrade will never leave an unbootable system behind as long as a previously working one is still installed. So if someone wants to experiment with u-boot-meson.bin, you have to let me know and I will upload the file. extlinux.conf

Congratulations, I'm glad that it works for your usecase. Since I don't have an eMMC, it was just a shot in the dark, thanks for the confirmation that it also works with an eMMC. Since the release is already near, it is not worth taking another intermediate step, since most likely nothing earth-shattering will be added in relation to ODROID-N2+: I could still offer v2022.07-rc4 as an upload if you like. The use of the rc version should have no meaning in relation to the ODROID-N2+ as long as no malfunctions are noticeable. And even if some mainline bug is identified, I don't think there is enough time to introduce a fix in the planned release. By the way, I run the firmware only from the SPI flash, and in case of recovery from the SD card. In the end it's just: dd if=u-boot-meson.bin of=/dev/mtd0 ; sync

The firmware (uboot) is loaded by the maskrom code in the safest and slowest mode to use only minimal eMMC requirements. When uboot takes over, an attempt is made to switch to a more efficient mode. If this does not succeed, it can lead to the observed behavior. Since I don't know if more recent uboot versions have already fixed a possible problem, I had offered my v2022.07-rc2 build for a quick test. Unfortunately, in the other thread it looked like the maskrom code couldn't even read the firmware blobs and without console logs it's not really to analyze. So if you want, try v2022.07-rc2 it's a simple: dd bs=512 seek=1 conv=notrunc if=u-boot-meson.bin of=/dev/${entire-card-device-to-be-used} ; sync

128MiB cma is probably not sufficient according to here:

The type of remote control does not matter as long as it operates near the 38kHz carrier frequency and a suitable rc_keymap.toml is loaded. The reason I used the RC-100 is because I'm using the SD card I originally set up for my NanoPC-T4, and there this remote was configured for rc-empty. Therefore, it worked out of the box. Went on to 5.19.0-rc3. And with the Enable-JPEG-Encoder-on-RK3566-RK3568.patch, a JPEG encoder is also available (videoX-infos.log). MGLRU is also pulled in again but only to see if it does not cause regressions with Odroid M1.

Thank you for the service to track the progress. Now I can pick up MGLRU again for the next 5.19.0-rc3 build. I have been using MGLRU patches since the first post of @jock. I have a habit of opening many pages in tabs in my browser. I use this as a resubmission function for pages I want to follow for a short time. Open tabs seem to have the habit of requesting more and more memory, even if they are not actively viewed. This leads to the fact that sooner or later memory swapping begins. When swapping starts, all swap space is used up very quickly and the system responds very laggy. My current workaround is to close and reopen the browser to free up the used memory. I then only reactivate the tabs of most interest, but over time I reaktivate more tabs and the game starts again. With the MGLRU feature in place, the situation seems to improve. Memory swapping seems to kick in way later and if swapping, filling up the swap space feels way slower. If you want, you can use my kernel build for a quick test. Because it is generic built, it should work for your devices. You probably need to use a suitable DTB, but this should not be a problem as long as it obeys the mainline bindings. You can put it alongside your current running kernel and decide at boot time which to run. If this experiment with my kernel fails in the end, at least you've learned how to keep as many kernels in place at the same time as your persistent space allows. See this thread for more details. For the first test you can use the 5.18.0-0.rc3 build offered there and then switch to my upcoming 5.19.0-rc3 build if suitable. Btw, my kernel is at mainline 5.18.0+ media subsystem wise.

Ok, I went on to 5.19.0-rc1. I was able to skip a lot of mainline commits from tobetter's tree because they landed, and for the remaining WIP commits, I switched to more recent ones. Some of the WIP commits are already in staging and will land sooner or later. For those who are interested, I have attached glmark2 logs. The performance is not yet overwhelming, only the basic functionalities have just landed. But the graphical desktop works pretty decently. So the fine-tuning season is open. And with the hantro decoder wired up, hardware-accelerated video decoding of H.264 and VP8 works up to 1080p. See fluster-run.log for reference. Went on to 5.19.0-rc2. And with the ir-receiver wired up, my RC-100 works out of the box. Rant: Why doesn't editing allow spoilers to be created with sections of code? glmark2-wayland-odroid-m1.logfluster-run.log