Live with the blob, and accept that the certification is quite meaningless if you have to do such gymnastics to get it.
And I kind of agree with them. If code doesn’t have DMA or network access, I’m pretty happy to treat it like the code in my microwave.
There’s firmware blobs in almost everything. I’d prefer them to be FOSS, but we all need to get things done :)
The FSF guidance on the co-processor exception is breathing room. I haven't read the fine print on what they mean by co-processor. My conjecture is that it was written at a time before these sort of architectures, and referred more to traditional GPU over pci-e like co-processors so that non-essential stuff can be excluded from requirements. In this case, you have single silicon, and single RAM. RAM needs blob for init. You claim that if you squint, you can see single silicon as multiple processors, and voila RAM init quandry is solved. That is purim's gymnastics.
Updatebale firmware With physical switch would be much better solution than completely non-updateable firmware.
- either you give your users an ability to upgrade the firmware, so they can RE it, write and use an open replacement
- or you don't give your users an ability to upgrade, which doesn't help anyone since they can never be sure if the chip manufacturer didn't put some undocumented interface somewhere that even you weren't aware of; so now only the chip manufacturer can upgrade the firmware and the user can't
Realistically, in a context of mobile phone components, there hardly such thing as "not updatable firmware". You can never be sure.
Crypting and signing is trivial, so nobody is going to RE Intel ME or microcode updates.