For those with knowledge, capacity, and will, here is a task for the TODO list, if it's not beyond your ability: Apparently all DDR PHY manifestations require DDR4 "training" to work with DDR4 RAM. Training firmware blobs are currently all proprietary, binary only. The Librem 5 phone folks are not currently with someone who can reverse engineer and/ or reimplement such training firmware, and so are using an i.MX8 secondary CPU to perform this function, using the existing binary blobs. The ideal situation would be someone with enough knowledge etc solving this particular problem with a libre “training firmware” implementation. (Also, TPM-free Purism laptop models currently available on runout sale at ~$300 off - a very rare Purism sale (the TPM chip was so popular, all new models have it included by default).) Solving the first FSF RYF hurdle for the Librem 5 https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurdle/ … In U-Boot there are a number of firmware blobs that need to be loaded into the DDR PHY so that it can be trained to work with DDR4. This training is done on every boot. The normal boot sequence for the i.MX 8 is that the internal ROM loader loads the Secondary Program Loader (SPL) which, in this case, is a small version of U-Boot that can initialize the DDR and load the full U-Boot into DDR to finish the boot process. Very early in the SPL, the training blobs get loaded into the DDR PHY and the training sequence is run. The DDR training procedure is completely un-documented so re-writing the firmware blobs with free/libre or open source versions would be an arduous process. We can’t ignore the DDR PHY because it is interface between the i.MX 8 internal buses and the DDR4 chips outside of the SOC. The DDR PHY is also part of the i.MX 8 silicon so we can’t just replace the DDR PHY with a different one. It also appears that all DDR PHY’s required this training to work with DDR4, so going to a different SOC wouldn’t solve it either. ...