The i.MX8(M) boot ROM searches for an NXP-signed HDMI firmware image before even attempting to boot the main cores. If it does not find this image, or it is not signed, the HDMI block will be locked until next reset.
Therefore, it is impossible to ever replace the HDMI blob used by this device. The device could be used without this blob, but you then forego use of the HDMI (or DisplayPort) functionality.
Would this matter if the phone would not have a hdmi port but would use the usb-c to connect to a docking station with e.g. hdmi? (please forgive my ignorance)
I don’t know to which extent this is true.
Maybe it is only needed for DRM?
Or, it is needed, but secondary processors like GPU are counted differently (regarding RYF)?
I would be surprised if Purism had overlooked it:
Dose this include the displayport output? I read something about it in the nxp docs (this 1000 page pdf one with all kinds if details), but can‘t remember. Could have said its the same chip which either dose hdmi or DP as well as that they are different chips.
And i didn‘t quiet undersstand if one can initialise the hdmi chip without things like hdcp or not. Because i can understand, as in see why they do it profit wise not aproving it, to hold back these keys for content protection.
I ask because i think the usb-c dp-altmode will be used for the phone.
As the dev-kit uses an hdmi port, is this blob present in the current dev-kit images?
So just looked at the link again an saw there is a signes-dp-somthing in there also. So DP seams to make no difference
We certainly haven’t overlooked this. We’re tracking this topic internally, and because I don’t want to lie, I’m not going to say much until we have this 100% worked out.
That’s fair, et us know when you have news.
If this closed blob is needed for convergence/external monitor only give apply a kind of non free repos like debian, so it will be not inside the shipped phone but if someone need it could download
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.
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.
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.
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).
