PREBOOT delay. Is it possible to reduce it?

[andk...@gmail.com]

    Hi, I'm try to optimize boot time BeagleBone Black board. The forum already has a few helpful tips to reduce boot time in stage u-boot and linux kernel loading. But one question remains uncovered.

    I found that there is a delay (near 2 sec) between the power on and the emergance of first debug message on serial port. I wonder what's going on in those two seconds. Is it CPU initialization procedure, or the way to avoid jitter when plug in power supply. Is it possible to reduce this delay?

~[00:000] - plug in power supply

[02:291] ▒ <------- Look here [02:310] U-Boot SPL 2015.10-dirty (Nov 14 2015 - 13:18:58) [02:490] MMC: block number 0x100 exceeds max(0x0) [02:494] MMC: block number 0x200 exceeds max(0x0) [02:498] *** Error - No Valid Environment Area found [02:503] *** Warning - bad CRC, using default environment [02:519] [02:551] [02:551] U-Boot 2015.10-dirty (Nov 14 2015 - 13:18:58 -0800) [02:555] [02:555] Watchdog enabled [02:559] I2C: ready [02:613] DRAM: 512 MiB [02:661] Reset Source: Power-on reset has occurred. [02:665] MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 [03:112] *** Warning - bad CRC, using default environment [03:132] [03:207] Net: <ethaddr> not set. Validating first E-fuse MAC [03:249] cpsw [03:250] Hit any key to stop autoboot: 0 (autoboot.c) [03:255] gpio: pin 53 (gpio 53) value is 1 [03:330] switch to partitions #0, OK [03:332] mmc0 is current device

Regards.

- Andrey Kuznetcov

[andk...@gmail.com]

[andk...@gmail.com]

[andk...@gmail.com]

I have tried run defferent images from SD:

1.Debian 2015-07-28 console with u-boot v2015.01 writed to unallocated space in front of first partition - 2 second delay remains
2.Jessie Snapshot console with u-boot v2015.10 writed to unallocated space in front of first partition - 2 second delay remains
3. Angstrom v2012.12 (kernel 3.8.13) with u-boot 2013.04-dirty writed to FAT32-MLO BOOT partition - start immediately after plug in power supply


So, I assumed that the problem is in the method of placing the loader. But if replace u-boot v2015.01 with u-boot v2013.04, then delay disappears. The new version has something that leads to a pause. What could it be?

[Robert Nelson]

migration to driver model

http://git.denx.de/?p=u-boot.git;a=tree;f=doc/driver-model;hb=HEAD

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Rick Mann]

Robert, do you mean that U-Boot is migrating to driver model during that delay? Or the delay is the result of U-boot having updated to the new driver model?

If the latter, what's it doing during those two seconds? Is there any way to speed that up? Eventually, I'd like to have a very fast-booting BBB.

Thanks,

--
Rick Mann
rm...@latencyzero.com

[Robert Nelson]

>> migration to driver model
>>
>> http://git.denx.de/?p=u-boot.git;a=tree;f=doc/driver-model;hb=HEAD
>
> Robert, do you mean that U-Boot is migrating to driver model during that delay? Or the delay is the result of U-boot having updated to the new driver model?
>
> If the latter, what's it doing during those two seconds? Is there any way to speed that up? Eventually, I'd like to have a very fast-booting BBB.

For me, it was around the initial driver model merge that we got that
slight delay.

Of course, it might also be newer ddr timing init..

The slow down didn't really bug me so i never looked too deeply in it..

But if you guys want speed, switch to u-boot's falcon mode:

MLO -> kernel

vs:

MLO -> u-boot.img -> kernel

it might not be 100% evident, but you'll need to hardcode a lot of
stuff in MLO that u-boot.img currently reads from uEnv.txt

[Robert Nelson]

For other speed up's, look into the am335x_evm board/mux files, you'll
notice it relies on reading an eeprom over i2c.. A lot of that can be
factored out if you know exactly what board you have. (i2c can be
slow)...

[Rick Mann]

Awesome, thanks. Yeah, in my application, it's an appliance that will have very well-understood configurations.

--
Rick Mann
rm...@latencyzero.com

[andk...@gmail.com]

The actual reson for the delay was the increased cost of memory reservation, the size of which increased from 1 kb to 16 mb:

diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h
index 6982918..6e0bf09 100644
--- a/include/configs/ti_armv7_common.h
+++ b/include/configs/ti_armv7_common.h
@@ -127,7 +127,7 @@
 * we are on so we do not need to rely on the command prompt. We set a
 * console baudrate of 115200 and use the default baud rate table.
 */
-#define CONFIG_SYS_MALLOC_LEN (1024 << 10)
+#define CONFIG_SYS_MALLOC_LEN (16 << 20)
 #define CONFIG_SYS_HUSH_PARSER
 #define CONFIG_SYS_PROMPT "U-Boot# "

But you can completely avoid the loss of time if you omit the initial cleaning of the redundant memory:

#undef CONFIG_SYS_MALLOC_CLEAR_ON_INIT