[U-Boot] Configuring U-Boot through device tree (was: Minutes from the U-Boot Mini Summit 2013)

[Wolfgang Denk]

Dear Dirk,

In message <526E9740.3070204 at 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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Boss, n.: According to the Oxford English Dictionary, in  the  Middle
Ages  the  words  "boss"  and "botch" were largely synonymous, except
that boss, in addition to meaning  "a  supervisor  of  workers"  also
meant "an ornamental stud."