BBB requires non-free drivers for the GPU, which are a huge PITA even if you don't mind them being non-free. You would end up with more-or-less a Nokia N9 clone.
It's better to use something like i.MX 8M Quad - you may want to take a look at the Librem 5; or if you want something lower-end than that then there's also the PinePhone which is based on A64.
Why only that particular rk3399 board? My rock64 runs blob free, as I would imagine most rk3328 boards do. The rk3399 type c port does require a blob, but I guess that is optional and boards without the USB3 type c port do not need it. Other than that the only blob I need for my PBP is for the broadcom WiFi modem. Are there any ac WiFi modems that work without blobs? I have only seen the ath9k chipsets which top out at 802.11n
With that said, I worry an rk3399 would run hot in a phone. Hopefully the thermals on the rk3588 are better. But rockchip is dedicating die space to a poorly supported "neural processing unit" now, so we will have to see.
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.
It's better to use something like i.MX 8M Quad - you may want to take a look at the Librem 5; or if you want something lower-end than that then there's also the PinePhone which is based on A64.