And an answer was included in the Librem 5 community wiki.
There was a question whether it would be possible to get video out without an HDMI DRM blob, but the DCSS driver doesn’t need to use that blob and Guido Gunther has demonstrated that the Librem 5 is able to display video on an external monitor using DisplayPort alt-mode over USB-C without using proprietary software.
The uboot-imx repository includes instructions for obtaining proprietary DisplayPort firmware by Cadence Design Systems, Inc. from a firmware archive distributed by NXP. I assume that “dp” in “signed_dp_imx8m.bin” stands for DisplayPort, especially because there are also other firmware files in “hdmi/cadence” directory. There is also a script that obtains and copies that firmware. And it is added to the device tree of Librem 5.
Do I understand it correctly that a binary firmware is currently required to initialize DisplayPort on Librem 5? If no, why is that binary being included in uboot-imx? Does it apply to external display or integrated display?
Yes, it does. The SoC’s ROM reads and loads the firmware into the Cadence core without assistance of the bootloader, kernel or any driver, it’s just included within u-boot to have it placed where the ROM expects it to be. It only applies to external displays (HDMI/DP core).
It can be deduced from previous information. The firmware interacts only with DisplayPort hardware interface and only when the rest of the device is not initialized. So, it probably does not have access to sufficient information which would allow it to identify you and to discriminate against you. Because it is distributed by NXP without downloader’s identification, a supply chain attack would also not be targeted against you. Because there is no automatic upgrade for it on a Librem 5, you would have to upgrade it manually to be affected by any changes. Because of all that, I do not really see how can it be “mean” to you specifically. If it is or becomes indiscriminately “mean”, then it is just faulty. The firmware might, in theory, have some hardware incompatibilities, but the hardware component of the interface could have them too, so the firmware component does not increase typical associated risks.
That is my impression and I trust Sebastian on that because he saw the code that handles the blob and that code is openly available. If you ask another expert (or “AI” tool), it may make a difference whether they actually saw the code and understand the context of Librem 5. It is quite difficult to make the correct question.
What I am actually concerned here about are simply the bootloader packaging formalities. Das U-Boot bootloader is bundled togeather with firmware blobs into a container before writing it to the device. So, it is difficult to package only the uboot bootloader separately for any practical purposes, such as inclusion as a package into PureOS, or in another FSDG-compliant distribution.
Of course, it would be nice to have the source code for the blob along with documentation for the interface to use every opportunity to improve it.
I am currently running byzantium. Let’s say that I want to upgrade to crimson. Let’s say that word on the street is that an in-place upgrade is at this time a bit buggy or troublesome. So I decide to upgrade by reflashing. In that scenario, I think I do actually get a new uboot (if one is available) - and I may not realise that.
It is actually a bit more complicated than that. The DDR PHY and DP PHY blobs are not a part of Das U-Boot. They just happen to be bundled in a container together with SPL and Das U-Boot before they are written to eMMC in order for this SoC’s ROM to find them. So, you might perfectly realize that you get the new bootloader but fail to realize that you get some version of the blobs at the same time, even though they are not loaded by uboot but by the SoC’s ROM itself.
If one simply installs the new bootloader from the deb package from uboot-imx build artifacts from Purism’s GitLab instance, one might fail to consider the included blobs.
When one flashes an image to Librem 5, one might fail to consider the included blobs.
Unfortunately, this SoC’s ROM expects SPL, firmware, and Das U-Boot being bundled togeather. So, it is difficult to package them separately. And it is also difficult to make an image for Librem 5 without those blobs. So, it is also complicated to package the librem5-flash-image while complying with the FSDG so that the program’s default use is not installation of nonfree software.
I assume that it was achieved at some point for DDR PHY blobs when they were stored in the firmware jail. But they were moved back to free up the jail for wireless firmware when switching from Redpine to SparkLAN cards. I also have no idea wheather it is possible to jail DP PHY firmware.
That would be surprising. (The built-in display is DSI. So I don’t see why DisplayPort would be critical. That said, there are probably niche cases where a user wants to boot with an external display e.g. lapdock, and the built-in display is not working.)
That’s not exactly right - the reason why DDR blob is not on the SPI NOR flash as initially intended is the DP firmware, as this one can’t be moved away from the storage the SoC boots from, making the exercise with loading through the M4 core futile. If DP firmware could be loaded the same way, we could keep it on the NOR flash as well (there’s still plenty of free space there) and package u-boot in PureOS, but ultimately we can’t, so there’s no u-boot in PureOS.
Fortunately at least the bootloader with blobs can be stored on a separate eMMC boot partition, so the OS image does not have to bundle it at all.
Yup, while the DDR blob is necessary for any proper definition of booting the phone, the DP blob could be safely removed if you never use DisplayPort.
Do you mean that, after Librem 5 boots without the blob, a VGA or even some HDMI adaptor or dock could be used with a kernel driver support? I would expect the perfomance to be abismal even at low resolutions. One of the reasons is that such driver would be running on the main CPU of Librem 5.
I assume this means giving up on external screen output. Maybe in some cases it would be still possible but below the performance and quality levels practically required for Librem 5 convergence.
Considering how many design decisions in Librem 5 are made with convergence in mind, disabling it feels like a fundamental reduction in functionality. It changes what the device is. Instead of a device which is capable of being the heart of a lightweight workstation which you can carry away in your pocket with all your data and work in progress, it would be just a phone limited to the form factor which is more suitable for content consumption.
As far i know hdmi blob can not be removed if so it just not booting…as it is a crazy dep. booting. But as you knowing i not fancy like dos, maybe dos know a fancy hack for.
No. I just mean “Can you boot at all?”. That’s what I mean by “critical”.
Note also that, as far as I am aware, there is no VGA or HDMI support, and video is always DisplayPort out of the phone. What you do with it after that is up to you.
Many docks do indeed convert DisplayPort to HDMI, likewise an appropriate adapter. On the other hand, with a monitor that wants DisplayPort, including a monitor with a USB-C input, and including a lapdock, video remains as DisplayPort.
It would be. But not everyone wants to use convergence or even owns the necessary hardware to use it. So the choice, such as it is, is (theoretically) left in the hands of the user - and I guess that if the user made that choice then it is reversible.
