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

Simon Glass sjg at chromium.org
Tue Sep 13 06:52:34 CEST 2011


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.

Regards.
Simon


More information about the U-Boot mailing list