Hi all,
given that the current trend seems to be to let U-Boot handle all the DT overlay stuff, I have a few general questions about what this all means.
I agree in principle, that having DT stuff handled by the bootloader is the right thing to do. But there are quite a few downsides to this. Are they being addressed, and how?
- If the bootloader collects the overlays into a final DT blob, there is no way to control the order of initialization from within Linux. With the old system, I could load an overlay after doing some initialization, even after having started a program. This allowed putting the hardware into a certain state before giving control to a driver. I don’t see a way to do this with the new system anymore. Is there an alternative?
I have a concrete example: The timer driver doesn’t initialize when there’s no functional clock. If I want to clock one of the AM335x timers from an external clock fed in via TCLKIN, I now have to make sure the clock runs when Linux boots. What if my external clock source needs to be initialized first, before it produces a clock signal? How do I ensure that this initialization happens before the timer driver initializes?
(OK, I guess in this particular example, it would be a possibility to let the timer driver initialize the timer with an internal clock, and later switch to an external clock when it is available. But that raises the question how to control a clock muxer programmatically from user space, instead of having it set up via the DT.)
-
The U-Boot output isn’t accessible from Linux after booting. The only way to capture it is to have a debug terminal connected on bootup. While I can do that in the lab, it doesn’t help me when I have to collect diagnostic information from a (remote) user. Is there any way to capture U-Boot output to be used from within Linux after booting, or is there activity to implement this? Granted, this isn’t specific for DT Overlays, but the more functionality is covered by U-Boot, the more important this point becomes.
-
The DT source files are part of the Linux kernel source tree. If U-Boot is now responsible for the DT stuff, that seems misplaced. Do I have to expect a wholesale transplant of DT sources to the U-Boot source tree?
-
Is there any effort to reduce the confusion that this change is causing? I mean, some kind of explanatory page that doesn’t mention it between the lines in passing, but actually has a chance to get found via Google, and tells the story with some clarity, like “Oi people, if you’re doing DT overlays, this is what happens right now, this is where we are going, this is what it means to you, here’s the information you should read, and don’t let anybody confuse you who talks about kernels 4.9 downwards.”
-
It is not clear to me if this actually makes the DT stuff readonly by the kernel. Or are there still possibilities to modify things after boot time, i.e. by working with the /sys filesystem. Or is all of that now under driver control, and therefore out of DT territory? In general. I have found it very difficult to collect reliable information about the relationship between the DT and the stuff one can see and do in /sys. Are there any (up-to-date) places where this is properly documented?
Sorry for the length of this post, but I guess I need to get a full picture first, rather than asking about details.
Cheers
Stefan