jernej

That is default fallback resolution when kernel can't read resolution info from display (on all platforms and architectures). There can be multiple reasons, like cable, monitor, some kernel/driver issue...

Your understanding is incorrect: 1. VDPAU was used only with vendor kernel, which is obsolete for a long time. Armbian uses only mainline kernel. 2. No need to worry due to 1) 3. GPU doesn't do anything for video decoding. That's desktop PC concept. Embedded SoCs have dedicated VPUs (video processing unit). But it's true that ffmpeg need patching. More specifically, it needs v4l2 request api support. 4. That's not necessary if ffmpeg libraries are patched and installed system wide. Last but not least, v4l2 request video decoding support is tested only in Kodi GBM mode. This means that it must be started from console, when no desktop environment is running. Maybe wayland mode would work, but I don't know. Certainly it won't work under X11. You have to use software decoding there.

AFAIK, mainline kernel isn't meant to be booted in secure mode and this is just to allow BSP kernel to be booted. I might be wrong, though. Just try running in non-sec mode.

That's not true anymore. MPV support it via GPU rendering in v0.35 for both, X and Wayland. However, you still need patched ffmpeg for that.

yes

Latest stable version of mpv also supports video playback with patched ffmpeg, even in x11 and wayland. If Armbian would package such ffmpeg, it would make almost trivial for people to watch movies using mpv on desktop.

It has nothing to do with video decoding. Read posts right before yours.

NV15, although sounds standard, it's not. It's RK invention and used only (AFAIK) on their chips. So I would presume not many mesa developers are aware of it and even less care about it. Note, EGL has nothing to do with DRM planes. EGL lists format supported for GPU rendering and DRM planes lists formats supported by Direct to plane rendering. There is catch, though. ffmpeg must provide proper mapping to DRM descriptor. I have no idea if that's done for NV15 in ffmpeg rkmpp module. If that's not done, direct to plane method won't work. Note that I don't care about vendor solutions and I'm only indirectly involved with RK platforms, so I can't help you more.

Driver needs a bit of rework since Cedrus on H6 needs a bit different initialization. I guess you need this for video encoding?

You have a ton of posts on this forum which explain video decoding difficulties and what to do. Hint, GPU has nothing to do with it.

Well, if freezes it's doubtful that it will work with newer image. Your box is different than OrangePi board, so most likely reason why it freezes is that electronics is not compatible and you would need device tree file (HW description) tailored to your box. This is not an easy task for a beginner. You can copy 1 MiB from that image, starting at 8 KiB offset. However, U-Boot has many board related configuration hardcoded, so I can't promise it will work.

Bootloader has to be written to SD card at offset of 8 KiB. dd command for this would be: sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1k seek=8 conv=fsync NOTE: Replace /dev/sdb with proper path to your SD card.

ZQ value should be in decimal, so 3750393. Other than that, it should be ok. Just be sure to write U-Boot to right location. How do you write U-Boot to SD card?

It's not supported on H6 yet.

Uh, your box uses RAM with extremely low frequency. All images you tested have about 2 times higher frequency set. This alone is very likely the reason for non working RAM. Additionally, ZQ value is different, but usually that's not a big problem. With these two changes, you can already customize U-Boot config, build it and replace it on one of the images.

Please write in english, I don't speak russian. Yes. Most of them contains partial DRAM configuration. Not enough to configure DRAM properly, but enough for quick check. Just copy first 1 MiB from eMMC, you can use dd command for that. There is plenty of guides on net. You still didn't tell which Armbian image you tried to boot.

This was maintained right - obsolete vendor kernel which hinders many modern functionality (wireguard, for example) was replaced with mainline kernel, which receives non-stop fixes and improvements for the cost of not supporting some HW features, which still can be eventually supported. DDR frequency scaling is mostly regarded as power saving feature, so most people don't care if board consumes few mA more or less. Only recently such driver was added for Allwinner A64 and H5, but these are pretty different from A20, so driver most probably can't be easily extended.

You should tell which image you tried to use and in order to be able to do anything, boot log of original FW (probably Android) and extracted sys_config.fex or first megabyte of bootloader, so it can be extracted from there.