FSF recommends hardware which runs purely blob-free OSes. Such hardware can still have proprietary components, which can be considered "hardware, not software", i.e., have no access to RAM, CPU or network and do not require updates.
This was posted a long time ago. The phone has been available for a more than a year now and it still is not ryf-certified. I don't think it will ever be.
Have a look at my first link. FSF did not certify the phone, because they did not receive the units yet. Purism is struggling with delivery due to the supply chain problem. Nevertheless, FSF recommends Librem 5 every year, and they never recommend anything requiring binary blobs. I have no doubt it will be certified (later rather than sooner).
I couldn't find "FSF did not certify the phone, because they did not receive the units yet" in the links you posted.
Purism has been tight-lipped about getting ryf certification. These maneuvers around memory and hdmi look more like cheating to me. According to the links I posted, i.MX8 cannot be deblobbed. I stand by what I say: I don't think the librem-5 will ever get ryf-certified.
> I couldn't find "FSF did not certify the phone, because they did not receive the units yet" in the links you posted.
Just below the picture of the phone, first sentence: While we're still waiting to get our hands on one, this device looks promising: https://www.fsf.org/givingguide/v11.
> These maneuvers around memory and hdmi look more like cheating to me.
Why does it matter to you that a secondary CPU which has no access to anything runs proprietary blobs to train the RAM? Do you also care about proprietary firmware of SSDs (and avoid them)?
> > I couldn't find "FSF did not certify the phone, because they did not receive the units yet" in the links you posted.
> Just below the picture of the phone, first sentence: While we're still waiting to get our hands on one, this device looks promising: https://www.fsf.org/givingguide/v11.
I'd still argue that it is a bit different from "FSF did not certify the phone, because they did not receive the units yet".
> > These maneuvers around memory and hdmi look more like cheating to me.
> Why does it matter to you that a secondary CPU which has no access to anything runs proprietary blobs to train the RAM? Do you also care about proprietary firmware of SSDs (and avoid them)?
To makes things clear: I'm not opposed to the "secondary processor exception". In this case specifically, the firmware was artificially stored on a ROM chip, and copied from there to "a secondary processor" by the main processor to unlock a feature (train the RAM) to allow the main processor to work properly. This is a bit too much for me. Also, I'm not sure the HDMI initialization runs on a secondary processor.
Also, librem-5 getting ryf-certified would make me very very happy. I really would love to see this happen.
The "secondary processor exception" is abhorrent, it creates a perverse incentive for vendors who seek RYF to lock down firmware instead of leaving it open to reverse engineering and reimplementation by the community.
A better approach would be to require public documentation of which components are proprietary (for all processor ISAs, processors, other hardware, all firmware and all software) and what roles they play.
Purism solved the problem with the RAM here: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd....