No buildroot in software tree

The current Yocto release is a pre-release and is the first one, because we can build upon the NXP release and add our configurations and packages.

For the Buildroot release the versioning must be done manually, so it takes more time.

Also we are currently in the progress to get the kernel to version 5.4.24.

We will try to publish a Buildroot pre-release with kernel 4.14.98 in the near future.

Please excuse the inconvenience.

Your F&S support team

With this 5.4 release, we will join i.MX6, i.MX7ULP and i.MX8 to use the same code base and we will try to make the i.MX8 code work more in the F&S way of doing things, i.e. the way that our customers are used to. This requires some basic modifications (compared to the NXP way of doing things) in how we boot our systems, especially because some new boards will boot from eMMC only, so that our previous NBoot will not work in the same way anymore. Kernel is already ported to the new version, Buildroot and Yocto still require updates and of course U-Boot and the boot environment in general will still need some work. And of course a lot of fine tuning and testing of the device drivers. So we do not expect a regular release before November.

We are preparing a release for i.MX8MM at the moment. Then the other i.MX8 CPU variants will follow in the upcoming weeks.

Your F&S Support Team

Hi Support,

We are trying to bring up the EFUSMX8X-V4-LIN in our existing carrier board - which is made so it supports Both EfusA7UL-V4-LIN and EFUSA9X-V4-LIN and also the EFUSA9-V5-LIN. In this process we found that both the build rooth and yocto is quite early release. Now reading that you will launch a release for i.MX8MM which I guess is the picocore family I wonder how about the EFUSMX8X-V4-LIN we need the 2 ethernet ports and the efus concept. Can you give information on when you have real release ready..With the yocto tools we have brought the module up and running with ethernets - but we can not confirm all other interfaces.

Looking forward to having a reply soon

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