> Rockchip have sent a few patches to the TF-A project here to support [RK3588].. From TF-A we can now build a complete working BL31 and replace the closed binary blob with an open-source binary that we can compile ourselves.. There are still some missing parts and the most important that is remaining right now is the DDR training blob, which is still closed source.
Cleanroom reverse engineering for the purpose of publishing new driver code, to avoid legal/IP minefields, is super-expensive. It should be a much narrower scope to determine whether a binary blob's actions are limited to memory training, since there is no requirement to publish reusable source code.
Looks like Collabora is already monitoring the blob, so it's not entirely a mystery:
At the moment of writing this article, we have identified a few differences from the binary blob previously used, which we can highlight as following:
Binary BL31 contains some unknown code to get HDMI-RX PHY access working.
The cpufreq support in binary BL31 is different from TF-A.
There could be more issues that are unknown at the moment and users should be aware of it.
> That doesn't sound like DDR training to me. Maybe now you see the problem?
It is absolutely a problem, but it's bounded by the ability to inspect and question code/behavior outside the officially claimed rationale. We can prefer open systems and also shine a bright light on the behavior of closed systems.
> Rockchip have sent a few patches to the TF-A project here to support [RK3588].. From TF-A we can now build a complete working BL31 and replace the closed binary blob with an open-source binary that we can compile ourselves.. There are still some missing parts and the most important that is remaining right now is the DDR training blob, which is still closed source.