jernej

@XFer012Above DT change will most probably lock up CPU - CPU is changing clock from which it is running. Much safer bet is to change CONFIG_SYS_CLK_FREQ in U-Boot to the frequency you want. There CPU is first switched to alternate (slow) clock source and once main CPU clock is adjusted, it's switched back.

You can try with (but no guarantee) in cpu0 node: assigned-clocks = <&ccu CLK_CPUX>; assigned-clock-rates = <1080000000>; Safe default is set in SPL (one of the first things that's is done). Note that everything is done by community without any plan. I just told you current pattern regarding these things. It could be that someone would prepare such patches soon or no one would find it interesting enough to work on it.

Check ohci, ehci and usbphy nodes in my DT: https://github.com/jernejsk/linux-1/blob/h616-hdmi/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts#L134 and https://github.com/jernejsk/linux-1/blob/h616-hdmi/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi. You should make a patch which adds these changes to DT, add patch to build system and build image. You can probably get away with making DT overlay too. Note that these are developer level instructions - I don't plan to write more detailed steps.

that gets sorted out usually very late, when a lot of other features are already working. Those messages don't indicate alpha stage. Disabling just means that regulator was enabled at boot but Linux doesn't need it. "using dummy regulator" means that voltage regulator is not needed (vcc- regulators might get specified later but most of the time are not needed). syscon value message is imo useless and will probably get removed sooner or later. In short - several of these messages will probably stay in later, more complete kernel.

It's possible to make it work if you enable all USB nodes in DT. It seems like some HW quirk.

That's true. However, each platform must also define fdtoverlay_addr_r in default environment. Patches for amlogic and allwinner exist on ML, but I'm not sure for others.

That's from BSP kernel sources and can't be used as-is on mainline, which is what Armbian uses.

Ultimate check would be to read markings from RAM chips, check datasheet and calculate the size. If you can provide those markings and number of chips, I can do it pretty easily.

@Hemin@KY69 Note that if U-Boot detects only 2 GiB of RAM, you'll have problems once Linux tries to use that extra 1 GiB (writing to address 0 will be same as writing to address at 2 GiB - wrap around). So I highly recommend that U-Boot output is inspected on serial console. SPL should report 4 GiB and U-Boot should report 3 GiB.

This happens on all SoCs with DE2 or newer (A83t or newer SoC). Most SoCs have only one capable plane which can display YUV formats and it's always below current framebuffer, so that "workaround" (which imo is not workaround, but just part of configuration) is always needed in your use case. Note that having video plane below UI plane is actually desired for video players - UI plane has alpha channel which makes window with video transparent.

Good summary, let me clear some things. Having proper uAPI by no means makes libva-v4l2-request obsolete. If this lib is updated to latest uAPI, it still could serve as intermediate layer for all apps that don't support new interface but they support VA-API. Before you talked about libva-v4l2-request, which implements VA-API, so I wouldn't say it's irrelevant to ARM HW accel. libvdpau-sunxi implements VDPAU, but that works only on BSP kernels and it is not relevant for mainline. Further clarification: Kodi 19.0 (released recently) is highly recommended for all this - it doesn't require any out of tree patch for video decoding (LE uses patch for HW deinterlacing). Additionally, with version 19.0, there is single binary for all 3 windowing systems (gbm, X11, wayland). Depends on build options. Not sure if this version is available on Armbian but PPA exists, so I guess it should not be hard to test. H264, MPEG2 and VP8 should be good in mainline, although api can still change until codec is promoted to uAPI. HEVC still needs out-of-tree patches for any serious work. Maybe you can update your text, so we have current state overview in single post.

oh, there is plenty of bugs left to fix... but for normal use should be enough.

It's not a hack but missing clock initialization. I submitted fix to U-Boot: https://patchwork.ozlabs.org/project/uboot/patch/20210201172557.3776708-1-jernej.skrabec@siol.net/ Currently non-working features are scaling on video plane, YUV formats and resolutions > 1080p.

If someone has too much time, here is extremely basic and hackish H616 display driver (HDMI up to 1080p only): https://github.com/jernejsk/linux-1/tree/h616-hdmi (take branch as-is, USB works too)

Not sure what kind of hints you want, but yes, I think I mentioned already which patches needs to be taken and which ffmpeg config options needs to be used. but as JMCC said, it's best if you check LE sources on GH directly. Patches are regularly updated.

DRM properties are not meant to be used in device tree. First, driver must register them and use them(which sun4i_tv driver does not) and then user space app must set them via drm ioctl, but that usually goes through libdrm. Useful tool for DRM properties is modetest app, which is part of libdrm test tools. @guybrushthreepwood you'll be limited to SW decoding approach that way...

LE master branch and thus nightly images are using mainline kernel for a long time. But yes, download page will give you LE 9 based images, which are 4.4 based. LE10 is not that far away.

I made patch for clean kernel source. If that part fails for some reason, I would recommend to remove any other which would have that...

Yes, meson uses stateful whereas Cedrus and rkvdec use stateless (request api). Actually only one really worked on this driver but stopped working on most (all?) things due to real-life issues. Vanilla Kodi will work for video decoding, but if you want HW deinterlacing, that will need Kodi patch and additional one for ffmpeg.

The thing is that everything is in state of flux. Cedrus driver was first one which introduced new kernel API for video decoding, which is now also supported with rkvdec and hantro. You can imagine that a lot of stuff needed to be written. Only now interface is becoming stable and thus we can now start upstreaming changes. But that takes time... It's certainly possible to have great Kodi experience on Armbian, if you know what to patch. But currently it takes a couple dozens of patches at least for kernel and ffmpeg to achieve that, so I wouldn't recommend to do it yourself, except if you really want to learn how things work. Good thing is that with every kernel iteration, amount of patches is lowered.

I'm actually considering adding TV out support to LibreELEC. You would only need to specify overlay for enabling TV out. Would that work for you?

H3 doesn't use panfrost but lima. If you want to run Kodi efficiently, you'll need to pick a lot of kernel and ffmpeg patches from LibreELEC, manually compile ffmpeg and use Kodi without desktop. Oh, and you need Kodi 19 RC1, that probably means compiling Kodi too.

Good thing is that things are coming together slowly. There is a hack to make USB work and first part of display stack started to work (not usable yet).

With modern kernels there is no need to change anything for DVI, it's autodetected. I have DVI monitor (native, no adapter) and it works fine. Note that HDCP is not really supported on 5.10, so you shouldn't worry about it.

@Werner note that Linux v5 branch omits USB support for upstreaming reasons. However, if you pick v4 and this patch, USB should work well now. For Armbian purpose, v4 is better.