Since this is a portable battery-powered device, rather than first pushing to open-source the DDR training blob, which is non-resident in memory after it's done it's job and a fairly small binary (less chance for hiding bugs), I'd say it's more important to get open-sourced the support in the BL31 Trusted Firmware for dynamic voltage and frequency scaling of DRAM, and support for maximum power savings in suspend mode.
Rockchip have not fully open-sourced the DRAM DVFS support in BL31, but it's key to achieving full run-time battery life on portable devices - see https://xnux.eu/log/083.html
And the system suspend implementation that Rockchip did open-source in upstream BL31 lacks some functionality compared to their binary BL31, mostly about powering off as many peripherals as possible to save power.
I'm not saying don't bother opening the DDR training, just that these two things are much more important for a portable battery-powered device.
At least as of last week, people (mainly at Collabora) are working on open-source support for Mali “Valhall” including the GPU in Orange Pi 5. It’s just sufficiently different from previous generations to need a new driver, and taking a while to develop.
The actual SoCs used on each type of core module are somewhat well hidden (no mention on the main website as far as I can see) but can be found through a bit of research:
The boot ROM in the RK3399 in the PinePhone Pro has a hardcoded boot order, and doesn't use the special boot partition of the eMMC - it only looks for a bootloader on the data partition at a fixed sector (64).
I assume by "new API" for VMs on macOS you mean Hypervisor.framework, which is supported by qemu 4.0.0 and xhyve, both open-source. I wrote a blog article about using qemu with Hypervisor.framework to install Debian in a VM here: https://sigmaris.info/blog/2019/04/automating-debian-install...
Generally the SoCs used will have a separate video encoder IP-block that's not part of the Mali GPU. For example the "Cedar" video engine on Allwinner SoCs, Rockchip's VPU, Samsung's Multi-Function Codec, Qualcomm's Venus.
Instead of hiring enough humans to review the content they make money from, Google's approach to catching this stuff seems to be doing a global search for videos with "CP" in related text and auto-banning the channels: https://www.bbc.co.uk/news/technology-47278362 and then claiming that they're making use of "artificial intelligence" to moderate the platform.
Rockchip have not fully open-sourced the DRAM DVFS support in BL31, but it's key to achieving full run-time battery life on portable devices - see https://xnux.eu/log/083.html
And the system suspend implementation that Rockchip did open-source in upstream BL31 lacks some functionality compared to their binary BL31, mostly about powering off as many peripherals as possible to save power.
I'm not saying don't bother opening the DDR training, just that these two things are much more important for a portable battery-powered device.