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.
We've been getting these "almost there" announcements quarterly for multiple years at this point.