Let me give some background information.
The reason why the releases are really complicated this time is the fact that we do not think that NXP's way of grouping and installing the boot loader software makes much sense for an open platform like ours, where there are many different applications by many different customers. NXP always assumes that the user is the manufacturer of the whole hardware and also the developer of the whole software. For example if a manufacturer produces a sound bar for a TV, then he does everything from the hardware, over the OS, right to the application software. Then it does not matter if the software is slightly more complicated to install, it is just one software and it will work somehow and the software people know all the details anyway.
But in our case we just do a small part of the hardware and also only the OS part of the software. Our customers do the rest, and we do not have control over this remaining process. So we have a completely different situation. Our customers are not familiar with all the Linux and U-Boot internals. They want to write their high-level application software and do not want to bother about any low-level stuff. So it actually does matter if installation is complicated.
So why is it complicated? On i.MX8, there are quite a lot more files involved when booting the system compared to i.MX6. There is an ARM Trusted Firmware (ATF), there are DRAM timings, there is a DRAM Training Firmware and may be even a Trusted Execution Environment (TEE). Then we need a board configuration file. The new platforms are using eMMC for booting, too, which makes a method with hardware jumpers that we used with NAND in the past impossible. We now have to actually store the board identity somewhere in eMMC or NAND. There may be an additional HDMI firmware, and on i.MX8X, there are even more files like a SECO firmware and an SCU firmware. And so on and on.
This is all stuff that a regular customer is not interested in. It should simply work. But if we used the NXP way of installing software, all our customers would have to deal with all this low-level stuff. This would include downloading additional repositories, copying files from here to there and calling several build commands, just to get the image for the boot loader done. And as you can see, I also mentioned DRAM settings. The DRAM controller is far more complex now on i.MX8 as it can also handle DDR4 and LPDDR4. This means actually every RAM type, every RAM size and every board type with a different signal routing needs its own configuration. This would result in a separate boot loader for every single version of a board. Different RAM chip, different boot loader. Different RAM size, different boot loader. Different PicoCore or efus module, different boot loader. We would end up having literally hundreds of boot loaders for all our different combinations. This is not manageable, it does not make sense.
So we thought a lot about this and tried to do it better. And we were successful. We use a rather different approach now. Where "different" is only with respect to NXP. In fact it is rather similar to the way of installing software on our i.MX6 platforms, where a small piece of software called NBoot is always pre-installed on the board. This is how it will be on the i.MX8 boards in the future again. There is this pre-installed NBoot, and all the additional low-level stuff I mentioned is now included there and the customer does not have to care about it. He can build his U-Boot and Linux software exactly like before. Completely simple.
But what is looking so simple in the end was a tough piece of work to implement. We now have it done for i.MX8MM and are doing our tests right now. After that we can pack the first release. Then we will move on to the other i.MX8 variants, where we only expect minor modifications. Unfortunately i.MX8X is one of the more complex variants with regard to the boot process, so I'm not sure if it will be right the next one or if we have other CPU variants first that are more similar to the i.MX8MM. We have to discuss this internally how we proceed. But be assured that we'll keep in mind that you are waiting for it. We'll try as fast as we can. But two months are gone rather quickly.
I know this information is not very satisfying, but you also have to understand that it does not make sense to do any final releases with documentation and everything, that we also have to support for a long time, when the whole installation process will change again in the near future. So we waited until everything is available. This is the case now. The big implementation is done, Now we only have to do the releases, one after the other.
So please have some more patience.
Your F&S Support Team