I don't think there are any binary blobs in the normal atf+uboot+kernel boot path. The display will run without the mali, so. AFAIK it can be run entirely open source. There could be some additional hidden burned in place firmware to handle the early SPI/etc boot flow, but they actually document the cortex M0 mgmt processor as well. So that puts them ahead of basically everyone.
Not all the documentation is "good" the DDR controller registers are in the docs AFAIK, but lack a theory of operation section.
So, really as far as I know this is literally the most open A72 platform out there when it comes to docs you can get via google. The MALI being the problem, which means that one could consider one of the reverse engineered QC chips or the rpi better understood (because of the Adreno or vp9 efforts) but even then the documentation quality is worse.
If there are no blobs in the "normal" path, why isn't this device supported by mainline Debian without special patches? Is this code making its way into kernel/bootloader upstream so that distros can pick it up?
Not all the documentation is "good" the DDR controller registers are in the docs AFAIK, but lack a theory of operation section.
OTOH, there is example code in TFA for that, https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/...
So, really as far as I know this is literally the most open A72 platform out there when it comes to docs you can get via google. The MALI being the problem, which means that one could consider one of the reverse engineered QC chips or the rpi better understood (because of the Adreno or vp9 efforts) but even then the documentation quality is worse.