[U-Boot] Selectable / delayed initialization

[Simon Glass]

Hi,

When U-Boot starts up it initializes all the peripherals which are
enabled  This might include USB, I2C, SD/MMC, LCD, Ethernet, UARTs,
etc.

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.

Later when it becomes clear that USB and Ethernet are needed we want
to init those also. I suppose the easiest way of describing this is
that we want to have some 'level 0' init, then perhaps move to level 1
and init peripherals at that level, then perhaps to level 2, etc.
Quite often we will only get to level 1 before jumping to the kernel.

At the moment the U-Boot init code is spread around a bit - there are
files called board.c within arch/xx/cpu/, board/xx/ and arch/xx/lib/.
So it is hard to make this change just within a board file. Some other
files have big lists of init calls like stdio.c and serial.c.

I am thinking of creating a way of specifying a list of peripherals
which should be inited in each level, then moving all init code into a
function which knows how to init each peripheral. Then we can call
init_level(2) for example, to start up peripherals in that level.
Perhaps level 0 would be reserved for pre-relocation init.

I am interested in any thoughts that people have about this and
whether it might be implemented in a generally useful way. I am
assuming that a driver registration / initcall approach would be a
bridge too far for U-Boot at the moment, so I am thinking of a
function with a big 'switch' statement.

The other related issue is that I notice that the arch/xxx/lib/board.c
files are different but have a lot of common code. Is there some scope
for starting a common/board.c file which slowly builds up common
functionality so that over time we end up with only the
architecture-specific code in the arch/lib/xxx/board.c? If so these
these two goals could perhaps be progressed together.

Regards,
Simon