[U-Boot] Selectable / delayed initialization

[Mike Frysinger]

On Thursday, August 18, 2011 15:01:28 Simon Glass wrote:
> On Thu, Aug 18, 2011 at 11:54 AM, Mike Frysinger wrote:
> > On Thursday, August 18, 2011 11:59:35 Simon Glass wrote:
> > i dont follow.  before u-boot gets to command line processing (either the
> > "bootcommand" env var or user input), little to no hardware should be
> > initialized, only registered as available.  after that, what hardware
> > actually gets poked is completely user decided at run-time.
> > 
> > dont want to use usb hardware ?  then dont call "usb start".  dont want
> > to use network hardware ?  then dont do network commands (i.e. tftp).
> > 
> > what am i missing ?
> 
> 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.

> >> > arches calling i2c_init() in their arch/*/board.c are broken imo.
> >> >  only a few do it: arm, ppc, m68k.  the common "i2c" command already
> >> > takes care of exposing "i2c reset" for people to init this as
> >> > necessary, and other arches havent had any troubles that i can see
> >> > (certainly i know people have used i2c on Blackfin systems from
> >> > u-boot).
> >> 
> >> I feel the idea of calling i2c_init() multiple times with a speed
> >> parameter is not great. Perhaps the function is just misnamed.
> > 
> > perhaps it is more historical, but that is the current API, and it is
> > already called multiple times, so it's required to work.  i dont think
> > this has been a big deal so far for driver writers, but that doesnt mean
> > it has to stay this way.  but wrt your requirements, i dont think we
> > need to dive down that rabbit hole ... just kill off the explicit call
> > to i2c_init() in the arm board.c.
> 
> 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

> >> > LCDs should only get initialized if it's the splash screen, otherwise
> >> > i cant think of any reason that hardware would ever get touched.  so
> >> > if you dont want the overhead of programming that hardware, then dont
> >> > enable splash screen support ?  i cant see a situation where you'd
> >> > enable splash screen support but not actually show the splash screen
> >> > ...
> >> 
> >> Well often U-Boot is asked to set up the LCD so that it will work for
> >> the kernel. There may be a specific power-on init sequence to follow
> >> even if nothing is actually written to the screen. For example in
> >> Chrome OS we don't have splash screen support but still init the LCD.
> > 
> > ruh-roh.  i think this is generally considered the wrong way to do
> > things. the kernel drivers should be able to pick up the hardware and
> > have it work regardless of what the (possibly brain dead) firmware that
> > came before it did. relying on the hardware to be in a certain state.
> >  it's even better done in the kernel as there you can do the init
> > asynchronously whereas in u-boot, everything is single threaded.
> 
> 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.

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.

> >> >> To save time, reduce the amount of code executed and thereby improve
> >> >> security, we are wanting to initialize only some peripherals at the
> >> >> start. For example we might start up I2C and SC/MMC.
> >> > 
> >> > this is generally the policy now.  init code should only be
> >> > *registering* the availability of devices.  it shouldnt be
> >> > initializing the actual hardware until requested.
> >> 
> >> OK then I vote for a framework which understands this and calls driver
> >> init once (in a lazy fashion when needed if you like).
> > 
> > each framework should already do that.  if there's a specific one you
> > think is missing, then you should highlight it.
> > 
> > if you're talking about overhauling/unifying the driver model rather than
> > each one being open coded, that's a different thing.  but i dont think
> > your current requirements (as i understand them) necessitates such
> > effort.
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110818/4d66b2e6/attachment.pgp