[U-Boot] Selectable / delayed initialization

[Simon Glass]

Hi Mike,

On Thu, Aug 18, 2011 at 11:54 AM, Mike Frysinger <vapier at gentoo.org> wrote:
> On Thursday, August 18, 2011 11:59:35 Simon Glass wrote:
[snip snip]

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

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

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

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

Regards,
Simon

> -mike
>