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

login
register
mail settings
Submitter Simon Glass
Date Sept. 12, 2011, 10:04 p.m.
Message ID <1315865067-1443-2-git-send-email-sjg@chromium.org>
Download mbox | patch
Permalink /patch/114421/
State New, archived
Headers show

Comments

Simon Glass - Sept. 12, 2011, 10:04 p.m.
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@chromium.org>
---
 README                             |   11 +++++++++++
 arch/arm/include/asm/global_data.h |    1 +
 2 files changed, 12 insertions(+), 0 deletions(-)
Marek Vasut - Sept. 13, 2011, 3:10 a.m.
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@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 ?
Simon Glass - Sept. 13, 2011, 4:52 a.m.
Hi Merek,

On Mon, Sep 12, 2011 at 8:10 PM, Marek Vasut <marek.vasut@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@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
Marek Vasut - Sept. 13, 2011, 5:18 a.m.
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@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@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
Wolfgang Denk - Sept. 13, 2011, 9:47 a.m.
Dear Simon Glass,

In message <CAPnjgZ3kZJoAGJFkPkxQp+-jnztYECUaEtLZ0nvgzV1f-xUQgQ@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
Simon Glass - Sept. 13, 2011, 11:44 a.m.
Hi Wolfgang,

On Tue, Sep 13, 2011 at 2:47 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <CAPnjgZ3kZJoAGJFkPkxQp+-jnztYECUaEtLZ0nvgzV1f-xUQgQ@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.

Yes thanks for pointing that out. I am really thinking of the init
sequence in board_init_r() where we init NAND, MMC and the like. So
yes it makes no sense to blindly init everything we can find. The fdt
can provide a list of available options for each device type (although
in practice often it will provide only one option, perhaps with
multiple instances).

>
>> 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.

That's certainly the current approach, yes. It does work well I think,
and has the virtue of being simple, with minimal changes required to
code.

>
>> 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.

Yes, that's true and we mustn't do anything which blurs or weakens
that link. When I think of multiple LCD support for example, while
there is hardware support for it, do we have a need for it? Sometimes
this sort of thing is a solution looking for a problem. Yes it would
be easier to implement this feature with a unified driver model,
but...

On the other hand I think serial could benefit from a unified driver
model quite nicely :-)

>
>> 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.

OK good. There seem to be a lot of different activities going on, as
Graeme says in the other thread.

Regards,
Simon

>
> 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@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
>
Wolfgang Denk - Sept. 13, 2011, 11:57 a.m.
Dear Simon,

In message <CAPnjgZ1y+i0FdawcbBuOi0+SC+Xq3AS=ZZtTi1tVjv8CcNw6Og@mail.gmail.com> you wrote:
> 
> > 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. =A0It 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.
> 
> Yes thanks for pointing that out. I am really thinking of the init
> sequence in board_init_r() where we init NAND, MMC and the like. So

I'm thinking of that, too.  This list initializes a lot of things it
actually should not.  When this code got written, we had only a few
boards, an all init steps took just a few milliseconds, so it appeared
a good idea to print a "complete" system status at boot - always.

Now we don't consider this approach practical any more, especially
when targetting for short boot times.

When introducing a device model, one of the tasks will be to change
this part, too.

> On the other hand I think serial could benefit from a unified driver
> model quite nicely :-)

Agreed, and not only serial.

> OK good. There seem to be a lot of different activities going on, as
> Graeme says in the other thread.

Indeed.  I'm actually amazed how many different things suddenly start
moving :-)

Best regards,

Wolfgang Denk
Simon Glass - Sept. 13, 2011, 12:14 p.m.
Hi Wolfgang,

On Tue, Sep 13, 2011 at 4:57 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon,
>
> In message <CAPnjgZ1y+i0FdawcbBuOi0+SC+Xq3AS=ZZtTi1tVjv8CcNw6Og@mail.gmail.com> you wrote:
>>
>> > 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. =A0It 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.
>>
>> Yes thanks for pointing that out. I am really thinking of the init
>> sequence in board_init_r() where we init NAND, MMC and the like. So
>
> I'm thinking of that, too.  This list initializes a lot of things it
> actually should not.  When this code got written, we had only a few
> boards, an all init steps took just a few milliseconds, so it appeared
> a good idea to print a "complete" system status at boot - always.
>
> Now we don't consider this approach practical any more, especially
> when targetting for short boot times.

Oh OK, well that's actually quite good then. For one thing it means
that the idea of init order is perhaps not so critical, since we
actually want to remove most of this mandatory init. I mean that if we
are not trying to replicate the init sequence in board_init_r (but in
fact remove most of it) then things are simpler, and perhaps even fall
back to a call to the board code and not much else.

>
> When introducing a device model, one of the tasks will be to change
> this part, too.

Well it seems like it might fit quite nicely. For example cmd_usb can
make a call to get a USB driver pointer/context, which can do
start-of-day init if not already done. There are some complexities
with shared clock/pinmux config, but it shouldn't be too bad. It might
mean that U-Boot takes back control of firing off vendor init code,
currently done at start of day in board_init and the like.

>
>> On the other hand I think serial could benefit from a unified driver
>> model quite nicely :-)
>
> Agreed, and not only serial.

I admit I haven't been through every subsystem...

>
>> OK good. There seem to be a lot of different activities going on, as
>> Graeme says in the other thread.
>
> Indeed.  I'm actually amazed how many different things suddenly start
> moving :-)

Yes, it is certainly moving. Boot time optimisation, code
clean-up/rationalisation and run-time config should provide plenty of
impetus.

Regards,
Simon

>
> 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@denx.de
> There are no data that cannot be plotted on a straight  line  if  the
> axis are chosen correctly.
>
Wolfgang Denk - Sept. 13, 2011, 1:12 p.m.
Dear Simon Glass,

In message <CAPnjgZ0FvaM-dM0Af_ZiAT9EKho+zeT4HF_Vx9AqSXALp0pVhA@mail.gmail.com> you wrote:
> 
> Oh OK, well that's actually quite good then. For one thing it means
> that the idea of init order is perhaps not so critical, since we
> actually want to remove most of this mandatory init. I mean that if we
> are not trying to replicate the init sequence in board_init_r (but in
> fact remove most of it) then things are simpler, and perhaps even fall
> back to a call to the board code and not much else.

I think there are at least two parts of it.  One is driver init stuff.
Here it should indeed be sufficient when each command that tries to
open a driver will trigger the initialization of the device if thios
has not been done before (this sounds simple enough, but I see some
complexity because some of these things _will_ be done before
relocation, i. e. without BSS and without writable data segment, so we
only havce the space-limited gd ...).

The other part is board specific dependencies that are not that easy
to detect.

I consider it a pity that Detlev's suggestion went by uncommented:

http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/105824/focus=106328

The "init a driver when it's needed" is some automatic part of such
dependency base intialization.  Eventually we should follow that
method for the remaining parts, too.

Best regards,

Wolfgang Denk
Mike Frysinger - Sept. 13, 2011, 6:16 p.m.
On Monday, September 12, 2011 18:04:22 Simon Glass wrote:
> --- a/arch/arm/include/asm/global_data.h
> +++ b/arch/arm/include/asm/global_data.h
>
> +	const void	*blob;		/* Our device tree, NULL if none */

still "blob" and not "fdt_blob" ?  one man's blob is another man's blub ;)
-mike
Simon Glass - Sept. 13, 2011, 6:24 p.m.
Hi Mike,

On Tue, Sep 13, 2011 at 11:16 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday, September 12, 2011 18:04:22 Simon Glass wrote:
>> --- a/arch/arm/include/asm/global_data.h
>> +++ b/arch/arm/include/asm/global_data.h
>>
>> +     const void      *blob;          /* Our device tree, NULL if none */
>
> still "blob" and not "fdt_blob" ?  one man's blob is another man's blub ;)
> -mike
>

Sorry I did say I would change this - will do so before I send out a
real (not RFC) patch.

Regards,
Simon

Patch

diff --git a/README b/README
index 0886987..812805f 100644
--- a/README
+++ b/README
@@ -795,6 +795,17 @@  The following options need to be configured:
 
 		XXX - this list needs to get updated!
 
+- Device tree:
+		CONFIG_OF_CONTROL
+		If this variable is defined, U-Boot will use a device tree
+		to configure its devices, instead of relying on statically
+		compiled #defines in the board file. This option is
+		experimental and only available on a few boards. The device
+		tree is available in the global data as gd->blob.
+
+		U-Boot needs to get its device tree from somewhere. This will
+		be enabled in a future patch.
+
 - Watchdog:
 		CONFIG_WATCHDOG
 		If this variable is defined, it enables watchdog
diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h
index 4fc51fd..818eced 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -73,6 +73,7 @@  typedef	struct	global_data {
 #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
 	unsigned long	tlb_addr;
 #endif
+	const void	*blob;		/* Our device tree, NULL if none */
 	void		**jt;		/* jump table */
 	char		env_buf[32];	/* buffer for getenv() before reloc. */
 } gd_t;