[U-Boot] During boot is U-Boot doing its jobs sequentially or in parallel?
Hello again,
I recently wrote an E-Mail about silenting the output during the U-Boot sequence, but I thougt it's better to open up a new thread. BTW this is not a problem, I just want to know.
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:
- 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
- An image with U-Boot output, with network support in U-Boot- takes 12.30 s - An image without U-Boot output, but with network support in U-Boot takes 12.30 s too. --> 0 ms gained
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 ?
Kind Regards
Frank
Dear Frank,
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?
Q2: Do you actually have a plan for your optimizations, or are you just poking around at random?
- 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?
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.
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.
But of course none of this is present with an ancient v2010.06 U-Boot...
Best regards,
Wolfgang Denk
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
Dear Frank,
In message 5328485C020000460004BFD4@gwia2.rz.hs-offenburg.de you wrote:
Q1: why are you using so old software?
Because of some patches it's a big job to switch to a newer one.
Well, you cut yourself off from all nice features present in more recent versions...
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.
I'm sorry, but I do call this poking around. When doing optimizations, you should always start with measuring the current state first. Only when you klnow exactly hoiw long each step of the boot process takes you can determine where it makes sense to spend efforts on the optimization. Saving 50% of the time sounds great, but it means nothing if it's for a step that contributes only 1% to the total boot time.
Best regards,
Wolfgang Denk
Dear Frank Ihle,
On 18.03.14 13:21, Frank Ihle wrote:
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.
you should really consider updating your patches to current TOT and maybe bring them mainline to avoid further efforts in future. I recently attended Markus Hubig bringing Taskit's stamp9g20 mainline which was also based on some ancient U-Boot version. This was within his final paper where he also had to work on some other tasks I do not know of. He started somewhere in July 2012 by reading U-boot code and understand the concepts and brought his first patch beginning of August 2012 which where in mainline some days later then.
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
Most Atmel boards implement PHY reset by pulling the N_RST line for 200 to 500 ms. That could be your 200 ms boot-time saving without network support. I personally think the implemented PHY reset isn't necessary in most cases. The POR should be sufficient if the required I/O lines have the correct level at that time to configure the PHY correctly. However the software controlled PHY reset afterwards is required for some specific boards with weak pull-up/-down which are still in the field (some rev A eval boards). The mechanism is copied to some boards which may not need it then.
and is disabled with removing the lines above and setting
#undef CONFIG_CMD_NET
I believe this specific change is not required for saving the mentioned 200ms.
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.
Heiko hasn't sent his patches publicly yet AFAIK. I have some pre-version here, but they will not apply on current TOT and never on 2010.06. 2014.04 will be the first version with full SPL support for the first Atmel device (sama5d3xek). 2014.01 had support for MMC boot on that board, 2014.04 will add support for NAND and dataflash boot. Adding SPL for the other at91 is on my list, I still failed to get some time for that since last Christmas :( But there are some other boards using Atmel SoC mainlined these days (especially the siemens boards finished by Heiko), so I think we'll get basic SPL support for the at91sam9g SoC's soon.
Best regards
Andreas Bießmann
participants (3)
-
Andreas Bießmann -
Frank Ihle -
Wolfgang Denk