i.MX 8MQ system on chip in Librem 5 relies on Das U-Boot bootloader loading a binary distributed by NXP to initialize the RAM. The process of loading those firmware blobs into DDR PHY was described by Purism in detail.
This requirement is common for devices with DDR4 memory because it normally requires specialized hardware-specific initialization procedure for fine-tuning at boot time to reach higher speeds. Without that, devices either fail to boot, or run at some base RAM speed.
There are some exceptions. For example, RockPro64 used to require similar blobs too. However, Rockchip released some source code or documentation and the community reverse-engineered the blobs sufficiently to be able to boot without closed binaries in user-writable storage. It is now being applied to other devices with RK3399 system on chip too. Another example is Talos II and Blackbird from Raptor Computing Systems, where the microcode for DDR4 initialization was provided by IBM.
I got an impression that in both of those examples the chip supplier was in some kind of market situation that could pressure them to work with the community by releasing the code which they also had opportunity to release. The newer chips from Rockchip and IBM are back to requiring some closed firmware. Could NXP’s current situation be similar in any way? Does their primary focus on automotive and industrial applications affect it in any way?
How fair are the above observations? Is it unlikely that those blobs can ever be eliminated on Librem 5? Is there any expected future chip that may better fit Librem 5 requirements?
If the RAM firmware in Librem 5 becomes reverse-engineered, would it help only Librem 5 or some other devices too, such as iMX8MP-SOM-4GB-IND from Olimex, which uses i.MX 8M Plus? It was also used in some MNT products, but they moved to another chip. In other words, may there be a wider interest?
Finally, what arguments, besides freedom, could be in favor of freeing the code for those blobs? Are both potential security gains and improvements by the community questionable in this case?
There is the reliability aspect. It could happen that one day your L5 no longer works, because the RAM init thing is not working for whatever reason, and to make it work again you need to tweak something in that firmware. If you do not have the source code, then you cannot tweak it, so your device becomes garbage. Of course, this can be seen as part of the freedom argument, it’s one of the many reasons why you want freedom.
Now we are worse than before as WLAN(sparklan) initialization it need 3 BLOBs on Systems. The jail it just to deceive GNU. Thanks to Linux mainline for blobs.
There are constraints on this hypothetical situation which are necessary to keep in mind.
It implies that there is a change that may be necessary in the future. For the sake of argument, we could assume that some update to the firmware could be issued by NXP at some point to improve reliability or for other purposes. Alternatively, some other party could discover that a change is necessary even if it is not implemented, e.g. as a part of a security advisory.
It also implies that, for any reason, the improvement to the firmware by NXP is not the option. For example, an update works for i.MX 8M but does not work specifically on Librem 5 or does not work well, and NXP cannot figure out why. Alternatively, the system becomes obsoleted by NXP and they stop supporting it by the time.
This hypothetical situation apparently concerns “right to repair” and “planned obsolesce” topics.
Updates to DDR PHY by NXP do happen in practice. In principle, it could cover some fixes. But it is an unlikely attack surface and could be rolled back in case of reliability issues. This train of thought makes it look like the issue is not a big deal. The ability to upgrade the firmware instead of being hidden in hardware is also often marketed as an advantage from both “right to repair” and “planned obsolesce” perspectives, even when the firmware is exclusively binary.
This seems to leave us again only with the freedom argument. Either NXP or someone who licensed the DDR PHY to NXP can modify the firmware and to suggest others to upgrade while nobody else can modify it. The freedom argument, at least in the FSF’s interpretation, currently requires both sides to be equally inconvenienced, which means that either the firmware cannot be upgraded by anyone at all, including the manufacturer, or it is free and can be modified by anyone. When the firmware is non-free, this comes in apparent contradiction with “right to repair” and “planned obsolesce” concerns above. Probably because both also assume the right and ability to sufficiently reverse-engineer the blob.
Of course, all these concerns could be addressed by reverse-engineering. But I am not sure whether it is even legally possible for Purism as an NXP customer being bound by NDAs to facilitate it in any way. This is even before being able to address technical feasibility. In cases which I referred to above in my previous post, the manufacturer actively removed legal barriers when facilitating community reverse-engineering efforts.
To further separate the binary blobs from the A53 cores, we will add an SPI flash chip to store the firmware. The SPI flash will be read only so the firmware blobs can’t be modified without the user knowing.
Was the firmware jail implemented for DDR PHY? Or is it downloaded and rewritten to eMMC each time Librem 5 is reflashed?
I would like to understand why it’s proprietary. Having it open seems easier for everyone involved.
Is it the NXP company who have decided that this software should be closed? If so, what advantage is it that they imagine they are getting from keeping it closed?
Purism bundles DDR PHY blobs with Librem 5 bootloader in u-boot-librem5 package. Because PureOS cannot contain blobs while maintaining its FSDG compliance, that bootloader package cannot be included in PureOS apt repositories.
The package includes a copyright file, but only for Das U-Boot. Why is no copyright notice for the DDR PHY included?
The code in uboot-imx repository in Purism’s GitLab indicates that Purism obtains IMX firmware, including the LPDDR4 training binaries, from NXP’s website. Also, the paths for copying the firmware hint that the blobs are stored in the downloaded archive in “synopsys” directory. Maybe the blobs originate from Synopsys? It is likely if NXP licensed the memory interface design as an “IP block” from them.
The firmware archive 8.12 from NXP requires accepting NXP Software License Agreement v24. A newer version of that EULA can be found online. It declares that it applies to anyone using the software. So, doesn’t it apply to each Librem 5 user?
I wounder how much AI could make it easier to reverse engineer such blobs. I heard it is a good way to accelerate the reverse engineering process, but have no clue myself.
Not just DDRPHY but HDMI Blob too, so i guess that Evil_Opensource=U-Boot it have like 3 Blobs for L5 for booting…
About HDMI i can only full disable hdmi drm on host and monitor, as raptor computer shipped a unblob hdmi controller, meaning a hdmi connection without blob and drm.
open-source is cruel, heartless, and will not rest until kill free-software.
sometimes it is necessary to use the universal-language to illustrate the seriousness of something: a image.
The upstream U-Boot documented installation of the following DDR firmware for Librem 5. Only 4 files are needed. The rest, apparently, are copies and older versions. The files are quite small.
~/firmware-imx-8.15/firmware/ddr/synopsys$ LC_ALL=C ls lpddr* -la | cut -f 5- -d ' '
1668 Feb 8 2022 lpddr4_pmu_train_1d_dmem.bin
1668 Feb 8 2022 lpddr4_pmu_train_1d_dmem_201904.bin
1660 Feb 8 2022 lpddr4_pmu_train_1d_dmem_202006.bin
32244 Feb 8 2022 lpddr4_pmu_train_1d_imem.bin
32632 Feb 8 2022 lpddr4_pmu_train_1d_imem_201904.bin
32364 Feb 8 2022 lpddr4_pmu_train_1d_imem_202006.bin
1380 Feb 8 2022 lpddr4_pmu_train_2d_dmem.bin
1400 Feb 8 2022 lpddr4_pmu_train_2d_dmem_201904.bin
1404 Feb 8 2022 lpddr4_pmu_train_2d_dmem_202006.bin
23232 Feb 8 2022 lpddr4_pmu_train_2d_imem.bin
24308 Feb 8 2022 lpddr4_pmu_train_2d_imem_201904.bin
25456 Feb 8 2022 lpddr4_pmu_train_2d_imem_202006.bin
They are accompanied with “Software Content Register” file, which inidicates that the “DDR” component contains proprietary software from Synopsys company. There is no separate license for Synopsys DDR in Appendix A, so the terms are the same as in NXP Software License Agreement.
No, it is not NXP. Synopsys holds rights in the DDR PHY according to the above. According to publicly available information, Syponsys is a software company for electronic desing automation (EDA), but they also license IP blocks. Assuming that NXP licensed DDR interface design from them, it probably includes a hardware design and these firmware blobs as a part of that overall design.
The terms explicitely forbid reverse-engineering, decompilation, disassembly of the firmware. So, what we are discussing in this thread must be an attempt to write a substitute from scratch in “clean room” by analysing the hardware, not the blobs, to be legal.
I am now also inclined to think that development of a substitute is practically impossible without technical details from NXP and Synopsys about the hardware design.
In order to succeed, an “AI” tool requires some incremental feedback on what it does. There is no observable feedback that such tool could rely on for guidance in this case.
Let’s start a separate thread in the forum about it. I do not understand why they include it.
