[U-Boot] [RFC PATCH v2 1/6] fdt: ARM: Add device tree control of U-Boot (CONFIG_OF_CONTROL)

[Wolfgang Denk]

Dear Simon Glass,

In message <CAPnjgZ3kZJoAGJFkPkxQp+-jnztYECUaEtLZ0nvgzV1f-xUQgQ at mail.gmail.com> you wrote:
> 
> I would love to, yes. To some extent there is a bit of this already,
> at least for specific subsystems. Clearly the fdt would work better if
> we could just hand U-Boot the fdt and say 'init yourself'. It would
> then scan the tree and init all the drivers for all active devices.

No, it would definitely not do that.

U-Boot shall not initialize all possible available devices, but always
only those that it needs itself to perform it's task, which usually is
just to load and start an OS.  It makes no sense to initialize all
network interfaces (and eventually wait for the link to come up), to
initialize all attached disk drives (and wait for them to spin up) or
to scan the whole USB bus and initialize all attached devices when we
don't need any of these to boot the OS.

Suchinitializations shall always be done on demand only, i. e. when a
command is run that accesses any such device.

> However, we can achieve most of the aims using something along the
> lines of what I have proposed, where the existing call (say to
> nand_init()) can look up the fdt for its node, and then get the
> information it needs. The only really difference is the explicit
> hard-coded call to nand_init, rather than a general purpose routine to
> find a nand node and then locate a driver for it.

I can;t parse that.  Why cannot nand_init() do exactly what you
suggest, i. e. find a nand node and then locate a driver for it?
OK, by then it will probably be something like driver_init("nand") or
the like, but that's just a detail.

> To some extent that way of doing things would invert the way U-Boot
> currently works. It would also introduce questions about dealing with
> multiple devices of the same type (e.g. two different i2c controllers
> (not just instances) or driving two displays. These sorts of things
> are tricky in U-Boot at the moment.

Keep in mind that devices are always accessedonly on demand, so you
will have the needed information which device needs to be opened.

> So overall I think a unified driver model is a separate problem, and
> one that we should discuss and perhaps move forward on separately.

Agreed.

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
If you want strict real-time behavior, run in the real  time  schedu-
ling class.  But there are no seatbelts or airbags;  main(){for(;;);}
can hard hang your system.                          -- Bart Smaalders