3 ms·

> OSS TF-A at EL3 + closed DDR training (RK3588) That should be "blob which does stuff, including DDR training, at EL3". That blob certainly does DDR traini

> OSS TF-A at EL3 + closed DDR training (RK3588) That should be "blob which does stuff, including DDR training, at EL3". That blob certainly does DDR training. Maybe it does other stuff. But all of it is done at EL3. > In decreasing order of preference "Warning! Diagram is not drawn to scale."

transpute 2y ago
> That blob certainly does DDR training. Maybe it does other stuff. But all of it is done at EL3. If someone wants to find out, they can load it in IDA/Ghidra?
- karma_pharmer 2y ago
  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.

transpute 2y ago

> That blob certainly does DDR training. Maybe it does other stuff. But all of it is done at EL3. If someone wants to find out, they can load it in IDA/Ghidra?

karma_pharmer 2y ago
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.