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.