The i.MX8 cannot be deblobbed? (NXP-signed HDMI firmware)


@dcz Not to be an jerk, but why would Purism be stating that we are on the route to RYF certification?


Huh? Why would they not? We neither know officially whether (and how) a blob can be avoided, nor can we (at least me) rule out the possibility that the “secondary processor exception” can apply.


because there is still a few % mistery code left that is unaccounted for … RYF certification requires 100% de-blobbing.


Purism is not alone in adjusting/upbringing the both, Debian and i.MX8M SoC from just married stage to the perfect/mature one. This task isn’t easy for Purism alone and therefore SolidRun sees success in a long-term efforts from the general community. Topic related, about usage of custom Device-Tree Blobs is noted: “The flash-kernel application is used for installing DTBs to /boot as well as creating a boot-script for u-boot to load kernel, ramdisk and dtb.” Informatively and if interested, please read the rest here. It is just about understanding as I cannot help much with the real development (even though I wish I can).


Maybe there is something that we don’t know about, but Purism has either announced workarounds for the roadblocks to RYF certification or we can see how they can do it:

  1. All cellular basebands require a blob in the Linux kernel to function if used as part of the SoC or over the PCI bus, but Purism found one (Gemalto PLS8) that doesn’t require a binary blob if connected via USB 2.0.
  2. No 802.11ac chip exists which operates without a binary blob in the kernel, and the only 802.11n chip that operates over the PCI bus without a blob is the Atheros AR9281, which has bad reception and requires a blob for its Bluetooth, so Purism found a chip (Redpine Signals RS9113) that can operate without a kernel blob over SDIO 2.0.
  3. The i.MX 8M requires a binary blob to train the DDR PHY for DDR4 on bootup, so Purism is going to store the binary blob in a separate Flash memory chip that won’t normally be changed so it effectively becomes hardware and then have U-Boot execute the binary blob during bootup on a separate Cortex-M4F core, so it is separate from the other cores and their memory.
  4. We don’t know how Purism will get around the HDMI binary image required by the i.MX 8M, but it will probably have to put a separate chip on the board to convert from MIPI DSI to HDMI alt mode and/or DisplayPort alt mode over USB 3.0.

Do you know of any other binary blobs that are needed by U-Boot or the Linux kernel?


Either way, they are working hard to do the right thing!


@kieran I’m not fully certain, they have made many other BS remarks.

Coreboot Article | Purism & Libre

Coreboot Article | Purism & Coreboot

I’ll be interesting to see how this plays out.

For all I know, ThinkPenguin seems to be doing more to help the community.1

Archive of Post