[U-Boot] RFC: postload: Loading some U-Boot code later

[Simon Glass]

Hi,

I am looking to implement a feature where a cut-down U-Boot is
initially loaded, which is enough for a normal boot. But then when an
abnormal boot is required (e.g. from a USB stick or network), we can
load more code to cope with it.

Why?
- Improves security by not loading code that we shouldn't execute
- Speeds up boot by loading less code (we are targeting very fast boot
time and 100ms is worth chasing)

My current thinking is a system where the optional code is kept at the
end of the image in a post-load area and loaded when needed. Given
that, I am thinking:

1. We use the CONFIG items to find object files which can be made
optional. For example, CONFIG_CMD_ECHO controls whether cmd_echo.o is
linked in. So if we don't need the echo command in the normal case we
can move it to the 'post-load' area.

2. More extreme: we could do a build of a cut-down U-Boot for analysis
purposes, and compare the functions linked with those in the full
U-Boot. When building the full U-Boot, all the functions which are not
in the cut-down one can go into post-load.

2a. For simplicity, don't do anything special with data and bss -
these stay at full size.

3. Control the build using a new 'build-select' file which specifies
which CONFIG items are essential and which are normally not needed.

4. We need to adjust the link script to move the objects around. The
generation of (parts of) this link script would need to be under
control of the build-select file.

5. Provide a function like postload_load_chunk() which loads a chunk
of code when we decide we need it. This can be called within U-Boot
when/if needed. It loads the code from flash, relocates it and returns
with everything ready.

I am interested in any thoughts that people have about this:

- has this been done before, or something similar?
- any hints, tips, dragon warnings?
- does the above approach sound reasonable?

Thanks,
Simon