5 ms·

> we're building secure by default Wi-Fi routers In addition to RPi hardware, it would be helpful to support Rockchip RK3399 and RK3588 SoCs that have minimal

> we're building secure by default Wi-Fi routers In addition to RPi hardware, it would be helpful to support Rockchip RK3399 and RK3588 SoCs that have minimal binary blobs, since these can used with open-source Arm Trusted Firmware (TF-A) for secure boot, to ensure that only owner-authorized OS and firmware are running on the device. > Many cards which support WDS//AP-VLAN have no trouble with updating the BSSID. Do these M.2 WiFi cards support AP/VLAN and BSSID updates? Qualcomm Atheros QCA6174 Wi-Fi 5 Qualcomm Atheros QCNFA765 Wi-Fi 6

karma_pharmer 2y ago
Rockchip RK3399 and RK3588 SoCs Just so people don't get confused, there is a huge world of difference between these two chips. They are not in the same category. Rockchip RK3399 is 100% blobless. You even control the EL3 Trustzone Secure World! This is True Root. Rockchip RK3588 still needs blobs in EL3, the highest privilege level. We've been hearing rumors for years now about "oh they'll open source it next month for sure" and it.... just. never. happens. Please stop spreading this rumor. Source or GTFO, Rockchip.
- transpute 2y ago
  Feb 2024, https://news.ycombinator.com/item?id=39490540 https://news.ycombinator.com/item?id=39490540 & https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21840 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a... > 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.
  - karma_pharmer 2y ago
    Like I said: blobs in EL3, the highest privilege level. We've been getting these "almost there" announcements quarterly for multiple years at this point.
    - transpute 2y ago
      In decreasing order of preference: OSS TF-A at EL3 + OSS DDR training (RK3399) OSS TF-A at EL3 + closed DDR training (RK3588) OSS uboot + closed TF-A closed uboot + closed TF-A Those who need the features of RK3588 can compare it to competitors which are less open. Those who don't need the features of RK3588 can use the older and fully open RK3399.
      - karma_pharmer 2y ago
        > 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.
spr-alex 2y ago
SPR can run about anywhere docker can run. So if you have a linux system running docker with these, you should be good to go. We provide the OS images as one path to running SPR. We are currently looking at banana pi over rockchip but we are very happy to assist if someone has this gear. I don't have access to Qualcomm information but if you have those chips it will be under the output of 'iw dev'.

karma_pharmer 2y ago

Rockchip RK3399 and RK3588 SoCs Just so people don't get confused, there is a huge world of difference between these two chips. They are not in the same category. Rockchip RK3399 is 100% blobless. You even control the EL3 Trustzone Secure World! This is True Root. Rockchip RK3588 still needs blobs in EL3, the highest privilege level. We've been hearing rumors for years now about "oh they'll open source it next month for sure" and it.... just. never. happens. Please stop spreading this rumor. Source or GTFO, Rockchip.

transpute 2y ago
Feb 2024, https://news.ycombinator.com/item?id=39490540 https://news.ycombinator.com/item?id=39490540 & https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21840 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a... > 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.
- karma_pharmer 2y ago
  Like I said: blobs in EL3, the highest privilege level. We've been getting these "almost there" announcements quarterly for multiple years at this point.
  - transpute 2y ago
    In decreasing order of preference: OSS TF-A at EL3 + OSS DDR training (RK3399) OSS TF-A at EL3 + closed DDR training (RK3588) OSS uboot + closed TF-A closed uboot + closed TF-A Those who need the features of RK3588 can compare it to competitors which are less open. Those who don't need the features of RK3588 can use the older and fully open RK3399.
    - karma_pharmer 2y ago
      > 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.

spr-alex 2y ago

SPR can run about anywhere docker can run. So if you have a linux system running docker with these, you should be good to go. We provide the OS images as one path to running SPR. We are currently looking at banana pi over rockchip but we are very happy to assist if someone has this gear. I don't have access to Qualcomm information but if you have those chips it will be under the output of 'iw dev'.