frakkin64 Amlogic's codebase of forward-ported stuff started to mingle with the upstream codebase in their latest BSP release based on Linux 5.4, but for now they only adopted some things like crypto acceleration drivers which are quite simple. Otherwise it's simple, their kernel defconfg compiles their drivers, not the upstream ones, and everything remains separate. Over time I'd expect to see them align on core board support (which their developers are upstreaming) but they will keep all the media bits separate.
The clm blobs allow a board manufactuer to tune the wireless card for their specific implementation so they are board (not card) specific and thus not appropriate to use generically in "distro supports many boards" scenarios. It's a little different with e.g. RPi4 where we pull the firmware blobs from a repo dedicated to RPi firmware and we know they are only used with the correct board hardware. Lack of clm blobs is not the issue and the 'error' is harmless.
See https://github.com/torvalds/linux…a3c0cb287f6e223 for some history on the alignment message. I think it needs to be solved in brcmfmac? - I'll ask maintainers again. The p231 dts inherits 50MHz from https://github.com/torvalds/linux…-q20x.dtsi#L262 as most of the reference boards have slow speeds set. The solution for that might be to create an upstream board dts for Vero4+ that sets higher SDIO clock. Can you share "dmesg | paste" please.
MPEG2 should be supported (the codec is upstream) but no idea what state it's in - I'll have to go create media to test it.
tomaszc Collabora work on open-source Mali GPU support and also media codecs in Rockchip hardware which are derived from the same Hantro G1/G2 IP blocks that are also used in Allwinner SoC devices (so the upstream code overlaps and supports both vendors). They are not working on anything for Amlogic that I'm aware of, but we collaborate with them on other hardware.