Dear Dirk,
In message 526E9740.3070204@gmail.com you wrote:
At ELCE, I attended the Barebox presentation. One Barebox feature presented there was "Configure Barbox through device tree". So the Barebox people seem to have this already running for some selected boards. After their presentation I asked them "how do you decide which parts are configured in the boot loader, and which in the kernel, then?". And got the quick answer "in doubt, the configuration is done two times".
Do we really want this?
Well, basically yes, we have to do this.
If we use the same device tree for U-Boot and the Linux kernel (which most probably makes sense) do we really want to do the initialization part we do already in U-Boot again in the kernel?
We may not want to do it, but in general there is no way around it if you do not want to establish strong interdependencies of a kernel port for some hardware and a specific boot loader for that system - which is generally considered a bad idea.
It has always been a good idea for a device driver to not make any assumptions about the previous state of the hardware, and to perform all required initializations. In some cases this may be redundant overhead, in other cases it may be mandatory. We have seen cases (in real life) where certain pieces of the hardware have been used in different, incompatible configurations (say, the SCC port on a PowerQUICC CPU first as a serial port, then as an Ethenret port, and then again as serial) by using loadable modules. In such cases you cannot rely on any previous settings being passed on by the boot loader. Today, where even the hardware can be reconfigured under your feet (see for example Altera's SOCFPGA or Xilinx' Zynq) this may become even more important.
Also, I still believe it is a Good Thing (TM) for a boot loader to only initialize such hardware that it actually uses itself (the reasons have been discussed often before). One more reason for Linux drivers not to assume that all necessary initialization was already done.
Actually the same is true vice versa: the boot loader cannot know which drivers the Linux kernel will be running. We cannot simply turn on clocks in U-Boot based on the hope they might be useful for Linux, while the system will actually be running an application profile tuned for lowest possible power consumption, so we ruin their setup, or force re-init anyway.
I'm thinking about pin mux or clock settings described in the device tree, which are need to get the U-Boot drivers working. If these are done two times, then, what's about the risk of clock or pin glitches doing the same configuration in the kernel a second time?
I agree that such things need to be done really carefully to avoid such problems - but actually these are not really new. You have to apply the same care for the initialization already now.
Do we need a mechanism to do some configuration only at one place? Or isn't there any risk and we can do the same configuration two times? What do you think?
I think any such discussion depends on the answer of a few other questions:
* Will the Linux kernel accept to depend on specific features of a specific boot loader?
* Who is reponsible to define the interface between the kernel and the boot loader, i. e. for the decision which interfaces shall be initialized, and how?
* What is the API for such communication between Linux and U-Boot? Do we have a way to tell Linux about already initiualized interfaces (and eventually even as important: about their state)? How do we pass error status information to Linux?
Hm... while writing this my feeling that this will simply not work deepens. I guess, if you want to minimize overlap of activities, you will probably head for setups like SPL in Falcon Mode, where (in production mode) the overlap is at least minimized.
Best regards,
Wolfgang Denk