In message 53283CA4020000460004BF9D@gwia2.rz.hs-offenburg.de you wrote:
I realized a behavior of U-Boot, which isn't quiet clear to me. I have an ARM9 SAM9G25, that has this boot sequence: AT91Bootstrap -> U-Boot 2010.06 -> Linux 2.6.39. With that system I did 4 Test series about silencing the U-Boot output:
Q1: why are you using so old software?
Because of some patches it's a big job to switch to a newer one.
Q2: Do you actually have a plan for your optimizations, or are you
>just poking around at random?
It's not poking around, the aim is to see what effects do some options really ("atomically") have. I'm doing many measurements and always compared with a Buildroot defconfig that takes time around 10.6 s time from Bootloader to Userland.
- An image with U-Boot output, without network support in U-Boot - takes about 10.6 s to boot.
- An image like above, but without U-Boot output - takes about 10.4 s to boot.
--> 200 ms gained
I think it makes little sense to optimize the small parts - like some 200 ms here - when you appear to ignore the big chunks: a total of 10 seconds appears to be way too much. Did you a profiling of the boot process, so you can really focus on the big fish?
As mentioned above this is just one options of many I've tried, I already managed to boot the system in about 3-4 s (which now should be even less after I removed some further options). I know the "silent" option is more like out of a option group that gains the last 10 % of speed.
Now why is it, when I disable the output, the time stays the same with network support, but around 200 ms are saved without the network? One thing that comes to my mind U-Boot doing its jobs in parallel, is that true? Since there's a waiting when initializing the network there's enough time to do the output ?
We cannot comment on this, as we have no idea what your tests actually are, and what exactly you mean by "with or without network support". the general rule is that U-Boot is strictly single-tasking, i. e. there are no actions running in parallel.
I understand, well this is not a problem, I just like to explain the behavior. In case of interest here is how the network is enabled with the following commands
#define CONFIG_MACB 1 #define CONFIG_RMII 1 #define CONFIG_NET_MULTI 1 #define CONFIG_NET_RETRY_COUNT 20 #define CONFIG_RESET_PHY_R 1
and is disabled with removing the lines above and setting
#undef CONFIG_CMD_NET
If you are interested in short boot times you should look into using the SPL with Falcon mode instead. Heiko Schocher has some patches in the works to do this for the AT91SAM9G20 - here we do not need any Atmel code any more; we boot directly into SPL. So you could use Falcon mode and load Linux directly from the SPL.
That sounds interesting, I'll search the Internet about this, thanks for the advice.
But of course none of this is present with an ancient v2010.06 U-Boot...
Yes, then it would be another reason to double up the almost 4 years of U-Boot development.
Kind Regards
Frank