@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.
2 Likes
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).
1 Like
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?
9 Likes
Either way, they are working hard to do the right thing!
4 Likes
@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
While I’m all about de-blobbing and using chips that don’t require blobs, this is a difficult and slippery slope.
- What if the blob is stored in an eeprom? Is it then deblobbed? Of course not. The blob is there, it just lives in a different location. So going that route is actually stupid (more expensive) and the result is the same. The peripheral still needs external firmware.
- What if the blob is stored inside the chip? This also is actually stupid. Just because it’s an unchangeable blob, it’s still a blob. What’s worse, it can no longer be updated.
While there surly are peripherals that can function just fine without software, a lot of peripheral simply require software to run, especially radio technology. Saying radio X or radio Y doesn’t require a blob/software is just sticking your head into the sand, and having it in the file system at least allows for it to be easily updated.
I know Dr. Stalman had some issues with blobs and firmware in ‘ye-old-day’ but afaik has also come to the realization there is nearly no such thing anymore as ‘ROM’. A lot of stuff is simply software, and yes, we want to have the right to modify this software (think ath9k with its open source firmware), I think that (other then ignoring the fact that there is now a blob that you have less control over) its near impossible.
Mind you, I fully apologize if what you meant with ‘kernel blob’ was actually a proprietary driver. In that case, absolutely 100% correct! blob-drivers have no place in this project 
2 Likes
One person’s slippery slope is the road to freedom of somebody else.
Some have visions. Others say you should go see a doctor if you have them. 
4 Likes
Ah, but that’s why I actually prefer firmware in /lib/firmware. There you have a chance to liberate the firmware (see ath9k firmware). In eeprom you could still do this, if you manage to re-write the eeprom, making it far more difficult to experiment with. Which is why I am against the ‘deblobbing warriors’ where they prefer ‘sealed and locked’ firmware, just to avoid files in /lib/firmware.
If that makes sense?
Edit: Just reading up on the RS9113; so apparently, it has all the standard software stacks inside of the chip (e.g. software WLAN, bluetooth, zigbee ‘pro’ stack etc etc. However, if you can’t update it, and if you can’t ‘free’ the software (firmware). Though I think in our case, it would be the RS9113-NB0 (wifi, bt, no zigbee)? But atleast it seems that firmware should be upgrade-able…
As for the DDR4 core, storing it in flash, that’s just silly. It doesn’t ‘become hardware’. It just adds cost and complexity. The firmware is still there, the firmware is still executed, the firmware is still read by u-boot and the CPU. So what’s the advantage here? I do assume the m4 is part of the imx.8. Since we don’t know how they are or are not connected, we still don’t know the security/privacy impact there. I do wonder if it’s only initialization or if the firmware needs to stay active.
Edit. BTW, don’t get me wrong, I’m very much Pro RYF/FLOSS etc
1 Like
For RYF certification, embedded firmware is allowed as I understand it. The reasoning is (I think), that it could be implemented as hardware circuits just as well. That’s also the reason why, after reaching RYF, Purism will not stop there, because they want the schematics freed. At that point it becomes irrelevant whether the logic is in silicon or in software. It has to be free.
It remains to be seen whether we’ll live to see they day of a drive with all schematics and firmware freed. It certainly is a noble goal.
As a side point, there may be pros n cons regarding runtime-loaded vs embedded firmware, but there seem to be classes of devices where runtime-loaded just doesn’t make sense (like for drives). It should have something to do with chicken and eggs, but I just can’t think of it right now 
1 Like
haha, yeah, loadable firmware for your boot device is kinda, hmm. Looking at more embedded devices however, (well I think the same goes for nVME and SATA SSD’s) is that they do have their firmware embedded (for exactly this reason) but do have update-ablitlity. Of course reversing this, will take decenia, I don’t think there is a single attempt yet for any device (other then sprite_tm’s hacking).
There are a couple practical benefits to the FSF/Purism approach. First of all, it is much easier for the community to maintain over time U-Boot and the Linux kernel if they don’t have binary blobs. If all you have to maintain is the free/open source code to control the cellular baseband via USB 2.0, the GNSS via I2C, and the Wi-Fi/Bluetooth via SDIO 2.0, and you know that the firmware isn’t changing, then updating the Linux kernel is less likely to break the drivers and you know how to fix it if it does. In contrast, if a new kernel doesn’t work with the old binary blob, then you are stuck and can’t fix it. By using a standard interface (USB, SDIO, I2C, UART) which is documented by the manufacturer, you are less likely to run into incompatibility problems in the future than using the manufacturer’s proprietary driver in the Linux kernel.
The second benefit is that the proprietary firmware which is located on the cellular modem, GNSS or Wi-Fi/Bluetooth can’t access your RAM, Flash memory or CPU cache, without going through your free/open source driver to request these resources, whereas it can if a proprietary driver in the Linux kernel, so security is better.
It isn’t impossible to update the firmware located on a component, so these can be updated if you need to, but you know when it is changed, whereas you often aren’t aware that the firmware is changed when it is located in the Linux kernel. If you don’t know if you can trust a binary blob, you probably want to be in control when it is changed (although there is also the counterargument that the latest firmware will close known security holes).
Think of all the trouble that Purism has had trying to use the free driver in the Linux kernel for the Atheros 802.11n chip in the Librem 13/15. Those problems are less likely to occur if using the manufacturer’s provided interface over USB/SDIO/I2C/UART, so selecting chips that provide an interface of a standard bus (without DMA) and don’t require a proprietary Linux driver means less problems over time.
Again the benefit is that it is much easier to maintain U-Boot over time if it doesn’t contain any binary blobs, so all you are maintaining is the free/open source code which pulls the binary blob from a memory chip to execute it during bootup.
The benefit of having it execute on a separate CPU core is the cache of the Cortex-M4 is separate from the shared L2 cache of the four Cortex-A53 cores, so it can’t read their memory. This is probably isn’t a problem during bootup, since there probably isn’t anything important in the A53’s cache during bootup, but it is a good idea to not let a binary blob access the shared L2 cache during normal operation.
I think that there is also some power in saying we have a phone that doesn’t require any binary blobs in U-Boot and the Linux kernel, because it is setting a standard and isolating the binary blobs. It also gives Purism one more argument why binary blobs are bad when talking to a manufacturer like NXP. “Look you are costing us an extra $4 per device because we have to store your binary blob on a separate memory chip. Why don’t you release its code?”
5 Likes
There are a couple practical benefits to the FSF/Purism approach. First of all, it is much easier for the community to maintain over time U-Boot and the Linux kernel if they don’t have binary blobs.
As mentioned, I miss-took the blobs for firmware, rather then drivers. Blob drivers == BAD; blob firmware in /lib/firmware == shit, but acceptable as there is a way.
As for:
and you know that the firmware isn’t changing, then updating the Linux kernel is less likely to break the drivers and you know how to fix it if it does
This is a silly point. We have versioning for this. files in /lib/firmware can be versioned, and if the ABI is broken (either on the kernel side, or on the firmware side) the fix is just as easy, if not easier. But again, the opposite as mentioned earlier is, you can’t change it, so even if there suddenly is a major reversing effort, and the firmware becomes open source through reverse engineering, a ‘locked’ firmware will remain a blob. Again, see ath9k 
I think the interface of course, is completely irrelevant however. ath9k is in usb and sdio variants afaik, and you can use the vendor supplied blob, or the opensource compiled free blob equally.
TL;DR: If a new kernel needs the new firmware, then just copy it to /lib/firmware. If it’s “burned” into the chip or into eeprom, yes, then you are actually screwed.
Thinking about it, the current scenario is actually worse. If the vendor releases a firmware update for the DDR4 controller for example, due to a bug; and the kernel interface changes because of the new firmware, then this is easily remedied with the new firmware file. “Burned” firmware, can’t be updated on the fly, so also, screwed.
The only way this would actually work, is if the kernel devs would agree never to update the firmware and always use the older one, which, tbh, is quite unlikely.
It isn’t impossible to update the firmware located on a component, so these can be updated if you need to, but you know when it is changed, whereas you often aren’t aware that the firmware is changed when it is located in the Linux kernel.
Now, I explicitly mentioned in /lib/firmware a few times. This gives you the same control, just easier. Having it compiled into the kernel can’t even be done (easily). To build it into the kernel, the sources need to be available. The other option, is to package them compile time, which requires the firmware to be indeed available. No distro does this due to licensing. But yes, puri.sm could decide to do this, but then they are still in control. So no, I don’t agree with you point here. And if you do this, well then you are aware
Finally, as for updating via flashing external components (eeprom etc), this becomes super annoying if you need external programmers etc. or, in some cases, the programming documentation is simply not known. So again, doing it via /lib/firmware gives you the most freedom of the available scenarios
Think of all the trouble that Purism has had trying to use the free driver in the Linux kernel for the Atheros 802.11n chip in the Librem 13/15.
Without wanting to be rude, that almost sounds like incomentence. I worked for ultimaker for 4 years where we integrated a USB atk9k device into a olimex board. Where we only had one problem really, which was related to power on sequencing (and in the end, is a bug in the firmware, triggered by incorrect power sequencing/bad grounding). Wifi was fast, stable and completely free (we started with the blob firmware, until Debian added the free version into their default repo’s).
While I can see this depends on the chosen chip, the chip we used is ubiqous and very often used (because it is so free and works so well). In case i forgot to mention, https://github.com/qca/open-ath9k-htc-firmware is the ath9k firmware i am talking about. Btw, this is not reverse engineerd, but the actual source. So the earlier ‘blob’ and the free firmware are identical (if you could do reproducible builds, I’m just saying).
So out of curiosity? what interface was it? Because these devices aren’t even made without standard interfaces. PCI(e), USB, SDIO, SPI, I2C, UARt are the standard interfaces and are pretty much the only used ones.
Again the benefit is that it is much easier to maintain U-Boot over time if it doesn’t contain any binary blobs
Driver vs firmware again. I am not familiar with the DDR4 design or blob.
Comparing this to, for example intel, I know that intel needs actual code executed by by the CPU, to initialize the ram controller, after that, it just works. This was up until DDR3 the case afaik.
The scenario described by librem with the m4 doing things, it sounds like this code needs to ‘always’ run. And if that is so, the chosen solution does make sense. The m4 is (hopefully) fully isolated from the CPU (is it part of the SoC? then it may not be). However even here it holds, u-boot could, in theory, read the file from boot partition, and send it to the m4. Giving all flexibility and upgrade ability. The very hard problem here however is, the SPL needs to do this, and that is where it becomes harder, as the SPL is quite limited. Still, I still think this would be far better an architecture (With my current limited knowledge here). If however it is only to initialize the controller, then using the M4 is silly, especially if it costs money.
Now, as for having the blob in u-boot… you are responsible for the file (the blob) it’s versioned blob. Storing it in (EE)ROM does not make it easier, it makes it harder (excluding needing tools).
This is probably isn’t a problem during bootup, since there probably isn’t anything important in the A53’s cache during bootup, but it is a good idea to not let a binary blob access the shared L2 cache during normal operation
Now with all I said before, this does make it sound that the DDR4 code must remain active, even run time, and then, it makes complete and perfect sense to isolate this away (and hope the integrated M4 is cleanly separated). Using eeprom vs sending the file from u-boot however, meh; there is one benefit I can come up with, is that brick-ability becomes (slightly) reduced.
I think that there is also some power in saying we have a phone that doesn’t require any binary blobs in U-Boot and the Linux kernel, because it is setting a standard and isolating the binary blobs.
No, this is just sillyness and ignorance. I can’t see it, so it’s not there. The blob still exists, its still there, it’s still doing potentially doing evil things (think of intel ME), and makes life harder. Having it in an easily accessible place gives us a fighting chance
Now as for
“Look you are costing us an extra $4 per device because we have to store your binary blob on a separate memory chip.
This really depends of course on the situation and how this DDR4 controller really works. However, realize that NXP just buys the IP, and they don’t really care. “Voting with a wallet” doesn’t help in our niche, even how noble. Also they just may say ‘hopefully you bought our eeprom, we’ll give you a discount’ which just ends up being more money in their pocket.
Now if they where serious, they would have not used the i.MX8 that would have been a better statement.
Why don’t you release its code?
“because it’s not our code, so we can’t release it, sorry. talk to …”
The more we talk about this, the more it sounds like ‘runtime’ code, that’s always active, which would really suck. I really hope it’s just init code though.
Btw, runtime or init code, the code does have full access to ‘our’ memory of course. It talks to the memory controller, it can access every bit in the memory. So my guess is, that the m4 gets turned off after memory init, so this is not a problem. But then, the whole ‘l2 cache’ issue you mentioned above is moot also
2 Likes
The M4 core has its own separate cache and can’t access the shared L2 cache of the A53 cores. Yes, you are right that the M4 core will only be used by U-Boot, so it has no possibility of accessing the DRAM during normal operation, so we don’t have to worry about the security risk of malicious code in the binary blob to train the DDR PHY.
The issue is that the free driver has weak range, because they can’t figure out how to enable diversity.
It is a miniPCIe card and the ath9k driver, so I would assume that it is a PCI interface.
I would assume that Purism will provide a way to reflash the chip holding the DDR PHY training code, without having to open the case. It won’t be as convenient as changing the binary blob in /lib/firmware, but my point is that it shouldn’t be so convenient that you aren’t aware that it is being changed. On my laptop, I’m often not aware when the binary blobs in /lib/firmware are changed. I just upgraded to Debian buster, and I have no idea whether I’m using new firmware for the Intel Wi-Fi or not. By storing the firmware in a separate place, you are aware when it gets changed, because it isn’t part of the standard OS upgrade.
Also, if the community figures out how to make a free/open source version of the firmware, you can just update U-Boot to not use the firmware in the separate memory chip, but instead use the new firmware in /lib/firmware, so it isn’t a problem.
I think that a lot of this debate boils down to technical advantages in the short term vs trying to promote change in the long term. In the short term, it is more convenient to have the firmware stored in /lib/firmware, because it is easier to update as you say than having to reflash a separate memory chip.
Part of the goal is to make people aware of the problems of binary blobs, and create publish pressure to change the industry. NXP has responded to pressure and is now providing information so that free drivers can be created to control the Hantro G1/G2 video decoders in the i.MX 8M. By going through the extreme step of isolating the binary blob, you send a message to NXP. You are probably right that NXP can’t change it due to licensing agreements, but when NXP starts designing the i.MX 9, their engineers are going be thinking about the extra cost and engineering that Purism was willing to undertake. They are going to ask if they can find a DDR PHY for their next SoC that doesn’t require a binary blob to train it, because they don’t want to lose their niche as the best low-power SoC for open source projects.
Also think of the message which is being transmitted when thousands of people pay extra for a phone that advertises that it runs on 100% free software. It drives home the message to the hardware industry that there is public demand for hardware that doesn’t require binary blobs. You and I might know the dirty details about the DDR PHY, but the message is frankly more important than the details.
I am paying $599 for the Librem 5 vs $150 for the PinePhone because I want to send that message to the hardware industry. One of the publicly stated goals of Purism is to “drive change up the supply chain” and I want to financially support a company that is trying to reform the hardware industry rather than just accept the current situation and do what is convenient.
5 Likes
Ah, so it’s for training only. Ok, then yes, from the shared caches point of view, sure why not, but other then that, it adds very little. OTH, it doesn’t cost anything other then development time, so using the M4 is ‘fine’
Using a separate eeprom; … still doesn’t make sense, other then reduce the chance of brick-ability. Again, as the blob can happily live in the file system. However, I do realize it is easier to load the blob from i2c, then it is to load it from a filesystem (size limitation of the SPL).
The upside is however, this modification to u-boot can always be done, and the eeprom can be re-purposed for something else.
(which you mentioned lower yourself)
Also, if the community figures out how to make a free/open source version of the firmware, you can just update U-Boot to not use the firmware in the separate memory chip, but instead use the new firmware in /lib/firmware, so it isn’t a problem.
But I think DDR4, due to it’s super early need, is the exception rather then the rule.
but this is super personal/QA problem. As a user, you shouldn’t have to worry about this. You can safely expect this to just work.
As from the QA point of view, this is a serious issue, the vendor (purism in our case) doesn’t have things in place to properly test/validate this, Debian doesn’t either and just bumps the version without validating it works.
The solution however for the user is relatively straight forward. As the blobs are versioned, lock the version, and debian won’t update it.
As for the firmware/kernel ABI interface, you can put all the blobs in the world into eeprom; you can still not stabilize this ABI. Only one manufacturer has to use a ‘newer version because the vendor told them so’ and your entire system goes out the door. The kernel now has to support 2 ABI’s. So this is not a fix. The fix is, again, to use versioned blobs, and the kernel will only load the blobs it supports. So if only /lib/firmware/blob-v1.0 is available, it loads this. If v2.0 is available, it loads that. If it needs v2.0 it just errors on load, that it needs the new version (which in an fixed blob, means you are screwed).
Now, if there turns out a QA problem again here (firmware has a bug and fails to function, you have to rollback). And in that may mean, including the kernel. Or, support the older blob in the newer kernel
so see, the not-/lib/firmware blob does not solve any problem. And not locking the blob version, so you can update at your own convenience is more an incompetence problem (nofi).
I think that a lot of this debate boils down to technical advantages in the short term vs trying to promote change in the long term. In the short term, it is more convenient to have the firmware stored in /lib/firmware, because it is easier to update as you say than having to reflash a separate memory chip.
so you agree? 
I think having the firmware blob in /lib/firmware actually encourages hacking more (the barrier is lower, it is easier to start reverse engineering). Having to change an eeprom makes it harder.
As for DDR4, the situation IS slightly different (again, DDR4 is special in that regard). If you have the file on the filesystem, and your device fails to boot due to a hacking mistake, you need to be able to boot of an alternative media, to get an alternative blob. The technical solution btw is also relativily easy. Load from filesystem, if ddr4 init fails, try again, but load from eeprom as fallback so in this case, it makes hacking easier
They are going to ask if they can find a DDR PHY for their next SoC that doesn’t require a binary blob to train it, because they don’t want to lose their niche as the best low-power SoC for open source projects.
That really depends. Yes, if their chips are sold in interesting volumes to the open source community. OTH it’s all about money. If it is still cheaper, due to high-volume OEM’s not caring, they will still take the cheaper road. Every penny saved, means extra profit, or more likely chance to be chosen by an OEM.
There are a few things working for us however.
- Purism is a visible open source project -> marketing visibility, so yes, they may cater more towards our needs
- Even OEM’s in the end tend to use Linux, so having proper support, makes every one’s life easier. And in the long run, for NXP cheaper. By having blobs, they have to keep SDK’s for OEM’s updated. While the OEM doesn’t care what files are in their SDK, the maintainance burden can become overwhelming.
- NXP is struggling in the SoC market. While the iMX6 was popular for industrial applications, they lost out in all other markets. So they are probably really happy that people are using their chips. If however support becomes an annoyance, why wouldn’t av vendor pick something that is far better supported (means cheaper for the OEM). Because lets be fair, WE at least should know, that blobs in the long term, always is a support nightmare. EVEN for the vendor (NXP).
Also think of the message which is being transmitted when thousands of people pay extra for a phone that advertises that it runs on 100% free software. It drives home the message to the hardware industry that there is public demand for hardware that doesn’t require binary blobs. You and I might know the dirty details about the DDR PHY, but the message is frankly more important than the details.
No need to argue about this
But remember, I am only arguing, that ‘no blobs no blobs’ is not a solution. Moving the blobs, only changes the technical problem (harder/easier).
I am paying $599 for the Librem 5 vs $150 for the PinePhone
And that statement, is noble and makes sense. Not sure that it still is not overpriced, and most development may go to a whole new mobile OS; still, the goal is admirable.
As for the pinephone, they probably just use android, saving them a bunch of money. Also aren’t they from china or some other cheap country? Purism being american makes a huge cost impact as well. I don’t know their blobbing situation. I do know that Pine, uses a lot of allwinner components, and those are nearly completly reverse engineerd (actually, the older ones that run MALI are fully open source SoC’s).
I think the main difference, is that PinePhone wants to use existing parts to offer a libre solution, and purism wants to disrupt supply chain. In that case, I do favor the Purism of course, as this is far more important. Other vendors are in the ‘do the right thing’ whereas purism is trying to ‘force the right thing’.
Also, the pinephone doesn’t have glonass
1 Like
NXP produced 6000 pages of documentation on the i.MX 8 because industrial customers want it and they are willing to pay a premium for a chip that is produced for 10 years and is fully documented. I don’t think Purism alone is enough to make NXP pay attention right now, but a number of open source dev boards are also being produced using the i.MX 8M (Geniatech, Variscite, Myirtech, Digikey, Boundary Devices, Google, EmCraft), and NXP has to know that those boards are laying the foundation for future hardware projects.
My guess is that Purism will probably sell 10k Librem 5’s in the first year, however, if the number of apps grows, which I think will happen since it doesn’t look that hard to adapt a GTK desktop application to work on a mobile screen with libhandy and the Linux community is going crazy at the prospect of finally having a decent Linux phone. The Librem 5 threads on this forum get 5 times as many posts as the Librem 13/15 threads.
If the PureOS Store grows to a couple thousand mobile apps that solve most of the basic functionality that people need, I can see the Librem 5 blowing up and demand growing to a couple hundred thousand a year. The number of people who don’t want to share their personal data with Google and don’t like all the restrictions of Apple and don’t trust either company is huge. If just 1% of smartphone buyers decide that Linux’s ability to provide privacy+security+freedom are worth paying for, that is 15.5 million phones per year.
NXP will be paying a lot of attention if that happens, because there aren’t many SoC’s on the market that can serve the privacy+security+freedom market. The Allwinner A64 is hopelessly outdated, and Allwinner hasn’t released info for its more recent chips like the A80 so that free drivers can be created. Rockchip is probably the best positioned with its RK3399 and future RK3588, but its Mali GPU isn’t fully supported by the free Panfrost driver. NXP has the only low-power SoC on the market which doesn’t have an attached Wi-Fi/Bluetooth/Cellular/GNSS and has a GPU which can run with a free driver. Purism’s software development and GPL 3+ hardware schematics will make it easy for other smartphone manufacturers to adopt the i.MX 8M.
This could potentially become an important market for NXP, but it needs to produce a better mobile SoC to compete. The i.MX 8M at 28nm is not very energy-efficient and it needs Cortex-A7X cores to compete on performance. The i.MX 8M mini at 14nm is better on energy consumption, but NXP weakened the Vivante GPU, which was the i.MX 8M’s one strong point. The i.MX 8 has the A72 cores for good performance, but it wasn’t designed for mobile applications and sucks way too much power.
4 Likes
There’s a lot of if’s and hopes there
But I do share your hopes; if only they added NFC and QI for that cherry on top
As to stay on topic; as long as the display works without any problem, the HDMI blob is not that critical. The question is then, is the blob just firmware (from this thread I gather it as such) or actual driver. If the later, then yeah that sucks big time and needs to be RE-ed.
2 Likes
Up to mu understanding NXP i.MX 8QuadMax (MX8 and MX8QM) needs blob (IMAGE_BOOT_FILES += “hdmitxfw.bin hdmirxfw.bin dpfw.bin”), but the Librem 5 NXP i.MX8MQ doesn’t.
Initial wording: “Devices based on the i.MX8 or i.MX8M (such as the Librem phone or MNT Reform)” from https://www.devever.net/~hl/imx8 were misleading, as I see it now, because those two processors are not the same ones:
- https://github.com/Freescale/meta-freescale/blob/master/conf/machine/imx8qmmek.conf
- https://github.com/Freescale/meta-freescale/blob/master/conf/machine/imx8mqevk.conf
@amosbatto noticed this already.
Mainlining the DCSS driver will also be a huge effort… but NXP wants to look at it, so hopefully we will get both display port and HDMI support in mainline Linux in a not too distant future.
https://lists.freedesktop.org/archives/dri-devel/2019-May/219484.html
4 Likes