[U-Boot] Selectable / delayed initialization

[Mike Frysinger]

On Thursday, August 18, 2011 11:59:35 Simon Glass wrote:
> On Thu, Aug 18, 2011 at 8:33 AM, Mike Frysinger wrote:
> > On Tuesday, August 16, 2011 23:25:35 Simon Glass wrote:
> >> When U-Boot starts up it initializes all the peripherals which are
> >> enabled  This might include USB, I2C, SD/MMC, LCD, Ethernet, UARTs,
> >> etc.
> > 
> > i'm not sure about this statement.  many frameworks decouple the
> > "register" step from the "initialize the hardware" step.  i believe USB,
> > SD/MMC, and Ethernet (ignoring the MAC address issue) do already.
> 
> Yes that is true in many cases.
> 
> As an example, I feel it is best that most/all the code to do with USB
> sits in the USB driver. Let's say we have usb_lowlevel_init() which
> sets up the SOC and then usb_start() which starts up a particular
> port. Then I don't want to call either of these until I decide that
> USB is required. The way board files tend to work today is to just
> have a list of calls to init routines, then rely on #ifdef to disable
> what is not required.
> 
> My desire is to make the decision on what to init at run-time rather
> than compile-time. The boot moves through specific stages where we
> need to bring in progressively more smarts to complete sucessfully.
> Initially we can just use eMMC, then we find that doesn't work so must
> use USB or later maybe network. But we don't want to execute the init
> code for all of that stuff up front - and in fact if you saw my
> postload email, the code may not even be loaded at that point.

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 ?

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

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

> >> 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.
-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/410220c1/attachment.pgp