[U-Boot] Selectable / delayed initialization

[Simon Glass]

Hi Mike,

On Thu, Aug 18, 2011 at 8:33 AM, Mike Frysinger <vapier at gentoo.org> 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.

As you suggest there is the option of doing the bare minimum init and
then later when we do usb_start() we notice that we haven't called
usb_lowlevel_init() yet. If we have a proper driver framework then we
can keep track of which drivers have been activated, and activate USB
before it is used.

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

>
> a UART gets initialized all the time as it is the serial console ... not much
> to do here i dont think, and the overhead here tends to be fairly low as you
> program a few regs without polling for status updates.

Yes.

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

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

>
> i know NAND flashes misbehave, and i posted a few patches to fix that, but
> there was one or two edge cases that needed addressing before it could be
> merged.
> -mike
>

Regards,
Simon