I can live just fine with Micro USB 2.0 Socket 5 Pin (Type B) and HDMI (output) Micro Connector (Type D). Just one step back might make me happy like it is shown here:
By the way, this camera is one of the best money can buy right now and it doesn’t need USB 3.1 Gen 2, Socket 24 Pins, Type C. And, even though I am far away of being an expert, Debian (with Wayland) progress on i.MX8 is also not questionable, isn’t that correct? Still, if other Librem 5 backers insist on (need) USB-C (with a USB3.1 specification) coupled with i.MX8 please let me know, as I would like to understand this. Are USB 3.1 Micro-B + HDMI Type D (supporting up to 1080p) plugs an option? As minimum providing Superspeed USB 3.0 Type-A male to USB 3.0 Micro-B male cable would be necessary but providing HDMI Micro (Type D) to HDMI (Type A) cable should stay optional. Note: USB Type-C are just connectors and can run in any specification even USB 2.0.
Did i miss something? I thought this has nothing to do with connection types. Just that the i.MX8 is not able to do HDMI or DP (as protocol not as conecctor) with out these blobs. So if this data than is put through usb-c or any thing else seams totally unrelated and off topic hear to me.
Althought this wouldn’t mean it should be discussed , even if i think usb-c as a connector is set for some time.
All I tried to say is that I don’t care if digital interface is USB Type-C (USB3.1 Gen1) or USB 3.1 Micro-B but an additional HDMI Output would be nice to have while it belongs natively to i.MX8 (and as it is or may be influenced with here mentioned blob). Is avoiding HDMI output better solution (concerning eventual lower battery power consumption or any other improvement)? Newer Fujifilm cameras like X-T30 already use USB Type-C (USB3.1 Gen1) + HDMI Micro (Type D) Output because of improving its RAW conversion system.
Yes, within European Union is since 17 April 2019 enforced The Directive on Copyright in the Digital Single Market (Wikipedia link here). Initially NXT presented in 2013 plans to protect i.MX6 content with its Key Blob (shown on slide 18). It was de-blobed in 2017 (for Android) with best hopes for i.MX8. But today I am not thinking that i.MX 8 Series Applications Processors will be ever de-blobed and now my only choice is to use it as is or not to use it by accusing it is not being 100% free and open-source. Therefore I brought usage of USB 3.1 port for my own digital data and usage of HDMI for legal streaming (if somebody like me decide to have installed this particular proprietary blob and use it with Kodi … for example). As said I am not an expert but dreaming of something that does not exist is not my territory either.
As user I need a driver or my hardware doesn’t work and once we know that there is newer, better and hopefully with open source code we will use it. To sum up, to have this NXT key blob right away I see it as proprietary, but still quality advantage and not as a reason not to own Librem 5 because it is not 100% free software. I just think that losing i.MX8 video capabilities because of avoiding proprietary blob isn’t an option.
The i.MX 8M Quad SoC only supports USB 3.0, so the Librem 5 will be limited to 5 GBit/s (rather than the 10 GBit/s in USB 3.1).
It looks to me like the only way that Purism can solve this problem is to add a chip like the MegaChips MCDP2900 that converts from DisplayPort to HDMI or to add a chip that converts from MIPI-DSI Display to HDMI, but MIPI-DSI Display is limited to 1080p on the i.MX 8M. It seems a lot more likely to me that Purism will just support DisplayPort alt mode, and avoid these extra costs.
i.MX 8MQuad supports natively HDMI 2.0a Type-A connector. If binary blob in the i.MX 8M cannot be avoided is something that have to do with approach and attitude. I didn’t have in mind something like IMX-MIPI-HDMI in order to avoid blob nor that avoiding blob is must (for my needs). Anyway, thanks a lot for your effort and thoughtful input (indirect answer).
First solution wouldn’t work as the blob part is also true for displayport as far as i can see from the link in the original post.
The discussion about USB-C vs extra HDMI port is in my optinion point less as it is mixes protocols and connections as always with USB-C. The original problem is a protocol problem as the i.MX8 seams unable to produce a data stream of HDMI or DP without blobs, so its a protocol problem, and the connector problem is unrelated as USB-C has alternate roles for all the protocols (USB all versions, HDMI and DP ) to be transferred. So there is not difference for this problem what ever connector one uses.
But are there any news on this topic? @dcz
I checked the reference manual and it doesn’t say that DisplayPort needs the HDMI image. The HDMI and DisplayPort are generated by the same PHY, so the poster is assuming that the PHY won’t function at all without the HDMI image in bootup. He might be right that DisplayPort won’t function, but the bootup diagram shows that there is a bootup path if HDMI is not enabled. Based on what is in the reference manual I would assume that DisplayPort can function without the HDMI image, but I could be wrong.
It will suck if the PHY won’t function at all, because that means that Purism will have to convert the MIPI-DSI Display signal which is limited to 1080p at 60fps, whereas the built-in DisplayPort and HDMI support 4K@60.
I got the idea that dp also is looked down by reading bottom part of original source:
$ find firmware-imx-8.0 -type f | grep hdmi
firmware-imx-8.0/firmware/hdmi/cadence/signed_dp_imx8m.bin
firmware-imx-8.0/firmware/hdmi/cadence/signed_hdmi_imx8m.bin
it clearly has a signed blob for both dp and hdmi.so i concluded that both parts need to be signed by nxp.
But i might be wrong. I hope so. maybe there is an alternate way to bring up the dp output and this is just an hdcp protectet boot path.
I hope purism will not include this blobs but will make it available for people who need it.
It could be useful to join forces with MNT on this, since they are trying to accomplish the same thing. In their news blog they wrote
There are some avoidable features of the i.MX8M that currently require binary firmware to work. The first one is the Cadence “HD Display TX” HDMI controller: it includes an Xtensa-based “uCPU” that apparently controls HDCP, DDC and clocking for HDMI. You don’t need to use the HDMI port, though — an alternative is to connect a USB3.0 based HDMI or DisplayPort adapter with DisplayLink technology, for example.
Source https://mntmn.com/media/news_md/2019-05-20-reintroducing-reform.html
Useful too https://mastodon.social/@mntmn/102252513650044075
Yes, accepting several binary firmware blobs that are distributed under a separate NXP EULA might be necessary. i.MX8M comes with two display controllers:
- DCSS can be connected to either HDMI or MIPI-DSI (to LVDS bridge) and supports resolutions up to 4K,
- LCDIF can be connected only to MIPI-DSI and supports resolutions up to 1080p.
For Linux startup process, selecting display configuration is a matter of selecting an appropriate DTB file:
- Device tree blob for no display configuration,
- Device tree blob for HDMI display configuration (DCSS),
- Device tree blob for Display Port (DP) display configuration (DCSS),
- Device tree blob for LCDIF LVDS display configuration,
- Device tree blob for DCSS LVDS display configuration,
- Device tree blob for dual LVDS+HDMI display configuration,
- Device tree blob for Embedded Display Port (eDP) display configuration (DCSS).
@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:
- 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.
- 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 RS9116) that can operate without a kernel blob over SDIO 2.0.
- 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.
- 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