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

Marek Vasut marek.vasut at gmail.com
Tue Sep 13 07:18:01 CEST 2011


On Tuesday, September 13, 2011 06:52:34 AM Simon Glass wrote:
> Hi Merek,
> 
> On Mon, Sep 12, 2011 at 8:10 PM, Marek Vasut <marek.vasut at gmail.com> wrote:
> > On Tuesday, September 13, 2011 12:04:22 AM Simon Glass wrote:
> >> This adds a device tree pointer to the global data. It can be set by
> >> board code. A later commit will add support for embedding it in U-Boot.
> >> 
> >> Signed-off-by: Simon Glass <sjg at chromium.org>
> >> ---
> >>  README                             |   11 +++++++++++
> >>  arch/arm/include/asm/global_data.h |    1 +
> >>  2 files changed, 12 insertions(+), 0 deletions(-)
> > 
> > Hi,
> > 
> > do you actually intend to introduce some kind of a driver model to uboot
> > ?
> 
> 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.
> 
> 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.
> 
> 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.
> 
> So overall I think a unified driver model is a separate problem, and
> one that we should discuss and perhaps move forward on separately.

Well, I have this kind of stuff in mind and I plan to try pushing it as a 
university project in a month or so.

But (!) if you plan to init U-Boot according to FDT and I plan to add driver 
model, we should keep in tight contact so the driver model would be close to the 
FDT.

And yea -- dealing with the "dirty work" like fixing subsystems etc. would be 
part of the driver model stuff.

Cheers
> 
> Regards.
> Simon


More information about the U-Boot mailing list