U-boot - dependency management

Note: Because this question about U-Boot belongs to Linux, we moved this thread to Linux -> efusA9 category

Hello,

The migration to Kconfig in U-Boot is done in two steps.
First the Makefilestructure has changed. It is now (will say in current F&S U-Boot) more efficient than before. Here the Makefiles know the dependencies, the Build-Process is considerably shorter.
But the second step, the movement to a complete KConfig system with defconfigs etc. will be implemented with U-Boot 2014.10.

Best Regards
Your F&S Support Team

In U-Boot, the dependencies between different CONFIG settings were never checked in the past. It was your own responsibility to set all required and depending CONFIG defines in your .h config file in include/configs. Improving this situation was one of the reasons why the switch to Kconfig was done in U-Boot at all. The .depends files in the past were only for recording the include dependencies of the makefiles, not for checking any dependencies of the CONFIG switches.

As my colleague already said, the Makefile structure was switched to the new build system in 2014.07 (or even one or two version before, I can't remember right now). This already resulted in the short compile messages and that only those files are compiled that are actually enabled by CONFIG switches. In previous versions, all C files were thrown to the compiler and unused modules had to keep their code out by using #ifndef CONFIG_something.

Then in 2014.10, the full switch to Kconfig was done, with the Kconfig files, menuconfig and the defconfig files. As this introduced a rather dramatic change in the configuration, we stopped at 2014.07 the last time we upgraded U-Boot and only backported some minor features that we needed from 2014.10. The full conversion to Kconfig also took quite some U-Boot releases after 2014.10, where only a few CONFIG switches had been converted to Kconfig and others still needed to be set in the .h file. This resulted in a rather strange combination of .h config files and defconfig files which complicated the configuration considerably. This was the reason why we haven't had any U-Boot upgrades for a while. I hope that the transition to using defconfig files only is completed in the meantime.

In the next weeks, we are planning new releases for our software that will still be based on the same U-Boot 2014.07. But after that we will also upgrade U-Boot again to have full Kconfig support in the future.

Your F&S Support Team

We'll see. Device trees are a way to have a single U-Boot binary for different boards. Only the device tree is different. This is the only way for most manufacturers to get this done. But as the device tree of U-Boot is usually bundled with the code binary, then you'll have different U-Boot images for each board again. So in the end this advantage is not really visible to the customer anymore.

F&S has already put a lot of effort in U-Boot to get support for whole platform families. Our U-Boot provides this feature for quite a few years now. We really only have one U-Boot binary image for all our i.MX6 boards, even without using device trees. Yes, this is done in our board support code (well, actually architecture specific support code). But for the customer, this is more comfortable than a bad device tree solution.

One problem is evident with device trees: device trees are static. They contradict the idea of plug-and-play. To still support plug-and-play, there needs to be an instance that checks for actually available hardware in the current system. This is especially true for Linux itself. So in our view, U-Boot is the part that does this hardware checking, and then patches the device tree for Linux on the fly when it boots. But if U-Boot does this hardware checking, then it must know about possible hardware options for a board. So from our point of view, we can not get rid of board-specific code in U-Boot, even if we use device trees for U-Boot.

Let's do an example. We have efusA9 modules equipped with eMMC and without eMMC. But of course we do not want to have two separate Linux device trees, one with eMMC enabled and one with eMMC disabled. We can detect eMMC presence by looking at a configuration jumper, i.e. by reading a GPIO input. So our Linux device tree will always have eMMC enabled (status="okay"), but U-Boot will check the GPIO and then it will set status="disabled" in the device tree just before booting if eMMC is not available on the current board we are running on. But this means U-Boot needs to know about the possibility, that this board may or may not have eMMC. And it needs to know how to check this, i.e. by reading some GPIO. And it needs to know which node to patch in the Linux device tree. This can not be described in a static device tree for U-Boot, this has to be coded in board specific code. So we still need board-specific code in U-Boot. With this in mind, the use of device trees for U-Boot itself is not so self-evident anymore.

So it depends on whether device trees for U-Boot have other benefits for us. But as I said, the board-specific code will most probably stay in one way or the other.

Your F&S Support Team