[U-Boot] Selectable / delayed initialization

[Simon Glass]

Hi Mike,

On Thu, Aug 18, 2011 at 1:53 PM, Mike Frysinger <vapier at gentoo.org> wrote:
> On Thursday, August 18, 2011 15:01:28 Simon Glass wrote:
...
>> OK that's not how it is at the moment in some cases, but fair enough.
>> We have been pushing Tegra in that directly as it happens, but
>> certainly there is still a fair amount of mandatory init which should
>> be moved into / called from drivers.
>
> if there's specific frameworks/arches that always init hardware, then in
> general that's a bug and we should treat it as such (the u-boot policy doc
> explicitly bans this).  each framework (since they're all open coded in their
> own way) will need to be reviewed.  but hopefully there shouldn't be many.

OK

...
>> Er ok, but I found one in stdio.c!
>
> i'd also vote that as a bug :).  in looking at the history, i think this is
> just a really old wart that we should burn off (it predates the git history
> which goes back to 2000-2002).  if there are specific devices that need i2c,
> they themselves should be calling i2c_init().
>
> i know Wolfgang is sometimes hesitant to change these long seated things, so
> we might have to do what i was doing with the nand change ... the default is
> kept for a while, but people get a build warning if they are implicitly opted
> into the old behavior.  and if a board porter hasnt picked up their pieces by
> the time we drop the old behavior, well that's now their problem.  most people
> (the active) ones will continue to work.
>
> check out the commit here:
> http://git.denx.de/?p=u-boot/u-boot-
> blackfin.git;a=commit;h=df57f7de71fd1540991a0099be307a65679c53bb

OK I see.

...
>> We can't have a sensible console in U-Boot without keyboard and LCD -
>> for me the splash screen is a separate issue.
>>
>> Yes the single-threaded problem does make it tricky. Am thinking about
>> that problem now.
>
> if the hardware can be split up into the "prime the settings, wait for things
> to prime, and then do something else", you could (ab)use the current board
> callback system (where the board gets access to a few hooks along the way) to
> split up the LCD init so that the polling-some-registers part doesnt really
> happen.

Yes - would like to hide all delays behind other running code, without
firing up the second CPU. But LCD is the worst.

>
> if you wanted to talk about not touching the LCD at all *unless* someone
> wanted to interact with the keyboard, that might be an interesting discussion.
> we could add a hook to the shell interpreter where it would call a board func
> upon first user input.  then you could skip the LCD part in the default (since
> you just want to boot linux automatically), but if someone wanted to interrupt
> that and talk to u-boot to debug, you'd get a slight pause.  optimize for the
> common and make the uncommon [debug] step take a little longer.

That's exactly the sort of thing that I think a driver framework would
handle nicely, and generically.

...
>> I suppose the ad-hoc nature of drivers means that people miss the
>> 'generally accepted way' that things are supposed to be done.
>
> yes, but over the years i think (hope?) we've gotten better at catching this
> when someone submits something new.
> -mike
>

Yes, the code is definitely improving so I think you are right.

Regards,
Simon