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

[Simon Glass]

Hi Wolfgang,

On Tue, Sep 13, 2011 at 4:57 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Simon,
>
> In message <CAPnjgZ1y+i0FdawcbBuOi0+SC+Xq3AS=ZZtTi1tVjv8CcNw6Og at 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 at denx.de
> There are no data that cannot be plotted on a straight  line  if  the
> axis are chosen correctly.
>