HN user

sigmaris

49 karma

[ my public key: https://keybase.io/sigmaris; my proof: https://keybase.io/sigmaris/sigs/LF3GslvCVfgKWnevofqrcwFQT0snQK2pw9eFBRlx4U4 ]

Posts0
Comments14
View on HN
No posts found.

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.

Why I left Pine64 4 years ago

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).

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.