[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 at 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