>In message <53283ca4020000460004b...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot