4 ms·

If it was that easy we'd have a cleanroom FOSS implementation by now. It's been more than two years! https://wiki.raptorcs.com/wiki/Project_Ortega https://wik

If it was that easy we'd have a cleanroom FOSS implementation by now. It's been more than two years! https://wiki.raptorcs.com/wiki/Project_Ortega https://wiki.raptorcs.com/wiki/Project_Ortega

transpute 2y ago
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.
- karma_pharmer 2y ago
  > Cleanroom reverse engineering for the purpose of publishing new driver code, to avoid legal/IP minefields, is super-expensive Project Ortega did it to an entire gigabit ethernet controller for the princely sum of zero dollars: https://media.ccc.de/v/37c3-11781-adventures_in_reverse_engineering_broadcom_nic_firmware https://media.ccc.de/v/37c3-11781-adventures_in_reverse_engi... https://wiki.raptorcs.com/wiki/Project_Ortega https://wiki.raptorcs.com/wiki/Project_Ortega > Binary BL31 contains some unknown code to get HDMI-RX PHY access working. That doesn't sound like DDR training to me. Maybe now you see the problem?
  - transpute 2y ago
    > 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.

If it was that easy we'd have a cleanroom FOSS implementation by now. It's been more than two years! https://wiki.raptorcs.com/wiki/Project_Ortega https://wiki.raptorcs.com/wiki/Project_Ortega

transpute 2y ago

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.

karma_pharmer 2y ago
> Cleanroom reverse engineering for the purpose of publishing new driver code, to avoid legal/IP minefields, is super-expensive Project Ortega did it to an entire gigabit ethernet controller for the princely sum of zero dollars: https://media.ccc.de/v/37c3-11781-adventures_in_reverse_engineering_broadcom_nic_firmware https://media.ccc.de/v/37c3-11781-adventures_in_reverse_engi... https://wiki.raptorcs.com/wiki/Project_Ortega https://wiki.raptorcs.com/wiki/Project_Ortega > Binary BL31 contains some unknown code to get HDMI-RX PHY access working. That doesn't sound like DDR training to me. Maybe now you see the problem?
- transpute 2y ago
  > 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.