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