[U-Boot] During boot is U-Boot doing its jobs sequentially or in parallel?

[U-Boot] During boot is U-Boot doing its jobs sequentially or in parallel?

[Frank Ihle]

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

[U-Boot] During boot is U-Boot doing its jobs sequentially or in parallel?

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Science makes godlike -- it is all over with priests and  gods  when
man becomes scientific. Moral: science is the forbidden as such -- it
alone  is  forbidden. Science is the *first* sin, the *original* sin.
*This alone is  morality.*  ``Thou  shalt  not  know''  --  the  rest
follows."                                       - Friedrich Nietzsche

[U-Boot] During boot is U-Boot doing its jobs sequentially or in parallel?

[Frank Ihle]

>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

[U-Boot] During boot is U-Boot doing its jobs sequentially or in parallel?

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Nobody trips over mountains. It is the small pebble that  causes  you
to  stumble.  Pass all the pebbles in your path and you will find you
have crossed the mountain.

[U-Boot] During boot is U-Boot doing its jobs sequentially or in parallel?

[Andreas Bießmann]

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