firmware
firmware copied to clipboard
raspberrypi
RPi4: Long delay before booting linux after power on
On an RPi4 I am using Raspbian I am using bootloader: Mar 4 2020 14:24:08 version a445ea4fa94708c89875dbbb7a0b19e72987cbb2 (release) timestamp 1583331848 Linux retropie 4.19.66-v7l+ #1253 SMP Thu Aug 15 12:02:08 BST 2019 armv7l GNU/Linux
I'm seeing a fairly long delay before Linux starts booting after powering on my RPi4. I have a custom kernel module that starts ~2.5 seconds after "Booting Linux on physical CPU 0x0" according to dmesg. However it takes more than 9 seconds before I see my module running(it loads a splash screen via dispmanx). There is almost no delay from when my module loads and when the splash screen is displayed(tested via manually loading the kernel module).
I am using a DPI LCD. This uses the ID_SC and ID_SD pins for display purposes. I noticed early on that if I did NOT add external pullups on those 2 pins the RPi4 would get stuck there. The impedence of the LCD pins was such that the signal was less than 1v when the DPI LCD was attached. I could see the I2C sequence run by the PI on my scope. It just repeated indefinitely. After I added the pullups(10k at first and now I've tried 4.7k) booting worked correctly. But I see this long delay. I dont remember having this problem before. I expect a firmware update may have introduced it.
I have the boot splash(rainbow and raspberries) disabled and text disabled. It takes ~7 seconds from power on till I see the LCD dispaly a caret(eg when the RPi starts driving the LCD). Before this there is no signal sent to the DPI LCD(checked with a scope).
I tried adding "bcm2708.vc_i2c_override=1" to cmdline.txt but this doesnt seem to make a difference.
Any thoughts on what the delay is? Is there something I can do to reduce this delay. I'd like my splash to come up as fast as possible. 9 to 10 seconds may not seem that long but for a handheld PDA style device it is an eternity to have no user feedback after switching on power.
If memory serves correctly, you can disable the HAT eeprom scan with force_eeprom_read=0 in config.txt.
The HAT eeprom is read from the firmware, so nothing you add to the kernel command line will make any difference.
There are limits to how quickly the Pi 4 can boot - the SDRAM PHY has quite a lengthy training sequence, several seconds from what I remember.
Specifying start_cd=1 selects the cut-down firmware, which is smaller and loads quicker as a result. Otherwise keep config.txt as short as possible. You could also try experimenting with the initial_turbo setting which forces the system into turbo mode for a specified number of seconds at boot time.
A reasonable amount of time is taken up walking through the root directory checking for the existence of files because there is minimal filesystem caching. Removing unnecessary files from the boot partition and defragmenting might help a bit.
An explicit kernel=... and device_tree=... will also bypass any form of searching.
Here is my current config.txt
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
disable_splash=1
boot_delay=0
intial_turbo=30
start_x=0
enable_uart=0
audio_pwm_mode=2
dtoverlay=audremap,pins_18_19
dtoverlay=dpi18_2
dpi_group=2
dpi_mode=87
dpi_output_format=0x070016
dpi_timings=640 1 44 2 42 480 1 16 2 14 0 0 0 75 0 28000000 1
enable_dpi_lcd=1
#[edid=*]
#enable_dpi_lcd=0
If memory serves correctly, you can disable the HAT eeprom scan with
force_eeprom_read=0in config.txt. The HAT eeprom is read from the firmware, so nothing you add to the kernel command line will make any difference.
Whether I have force_eeprom_read=0 in config.txt or not the Pi still locks up if I dont have the external pullups on ID_SC and ID_SD.
There are limits to how quickly the Pi 4 can boot - the SDRAM PHY has quite a lengthy training sequence, several seconds from what I remember.
Specifying
start_cd=1selects the cut-down firmware, which is smaller and loads quicker as a result. Otherwise keep config.txt as short as possible. You could also try experimenting with theinitial_turbosetting which forces the system into turbo mode for a specified number of seconds at boot time.
start_cd=1 in config.txt doesnt appear to have any effect on boot limes. SHould that be in cmdline.txt instead?
A reasonable amount of time is taken up walking through the root directory checking for the existence of files because there is minimal filesystem caching. Removing unnecessary files from the boot partition and defragmenting might help a bit.
You can see my config.txt is about as small as I can get it so not much parsing going on.
An explicit
kernel=...anddevice_tree=...will also bypass any form of searching.
Can you provide an example of using these?
I'm not sure I was clear in my first post. This is the time from when power is applied till I see the DPI output start. About 7.5 seconds as I just tested before I saw the dot clock activate after power was applied. I've used Pi3s with DPI lcds and that time was at most 2 seconds from power till DPI was active. I could have sworn the Pi4 booted faster in the past. Specifically I had LibreElec running on it and could swear it was a couple seconds at most before the Libre Elec icon would show.
intial_turbo=30
There's a typo in this line. It might not have a big effect, but correctly spelt it might have some.
Thank you. That shaved 1 second off booting. Every little bit helps. :)
Nathan Scherdin
On Tue, Apr 21, 2020 at 3:50 PM Phil Elwell [email protected] wrote:
intial_turbo=30
There's a typo in this line. It might not have a big effect, but correctly spelt it might have some.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1375#issuecomment-617452789, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE3QXKOPWNJ3BEIPXAKN3TLRNYPKFANCNFSM4MMZXIEA .
If you just want the DPI output active faster then set up the DPI pinmuxing directly from config.txt instead of from an overlay that the kernel applies.
gpio=0-21=a2
an overlay that the kernel applies.
To be clear, the firmware would apply the overlay by loading the .dtbo file and manipulating the in-memory DTB. Each of those tasks takes longer than executing the gpio= setting. When the kernel starts it then has to make changes to the pin mapping based on the content of the DTB, which is going to take at least as long as the config setting - that's another saving. However, each of those tasks probably only takes a few milliseconds, so it won't be a big win.
Ill try it out. Thanks for the suggestion.
Nathan Scherdin
On Wed, Apr 22, 2020 at 2:49 AM Phil Elwell [email protected] wrote:
an overlay that the kernel applies.
To be clear, the firmware would apply the overlay by loading the .dtbo file and manipulating the in-memory DTB. Each of those tasks takes longer than executing the gpio= setting. When the kernel starts it then has to make changes to the pin mapping based on the content of the DTB, which is going to take at least as long as the config setting - that's another saving. However, each of those tasks probably only takes a few milliseconds, so it won't be a big win.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1375#issuecomment-617674564, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE3QXKOB4Y5VPWLQLPEIKQ3RN24SVANCNFSM4MMZXIEA .
@acidtech any progress?
I ran into the same issue, it takes a solid 6-7 seconds for the display to initialize, making the process of minimizing boot time quite unrewarding.
Yes, hopefully they can look at it in the future. I'm assuming the delay is loading/booting from the eeprom. It seems long though. Linux is definitely not booting during that initial 6 or so seconds. DMESG shows my on screen display runs at about 1.5 seconds and the first thing it does is popup the splash screen. For me thats 9 seconds unless I force_turbo=1 .
Unfortunately force_turbo=1 isn't a good option when overclocking the pi. Much higher chance of it locking up/corrupting the sd card, than if you boot under normal speeds but then you can't shave that extra second off. So looks like I'm stuck with a 9 second delay after power on before my splash screen can display. :)
Nathan Scherdin
On Mon, Jun 15, 2020 at 6:45 AM leragequit [email protected] wrote:
@acidtech https://github.com/acidtech any progress?
I ran into the same issue, it takes a solid 6-7 seconds for the display to initialize, making the process of minimizing boot time quite unrewarding.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1375#issuecomment-644144260, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE3QXKOWQ3XZ7I6OX3CJIV3RWYQWDANCNFSM4MMZXIEA .
@acidtech initial_turbo=10 should give you the benefit of faster booting without the downside of force_turbo. It will just force turbo for the first 10 seconds.
Sorry, my mistake. I ment initil_turbo, not force_turbo. To those that dont know, force_turbo=1 invalidates your warranty IIRC.
Nathan Scherdin
On Mon, Jun 15, 2020 at 9:56 AM popcornmix [email protected] wrote:
@acidtech https://github.com/acidtech initial_turbo=10 should give you the benefit of faster booting without the downside of force_turbo. It will just force turbo for the first 10 seconds.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1375#issuecomment-644251973, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE3QXKNFZYGGILR7ZAHKBU3RWZHCPANCNFSM4MMZXIEA .
force_turbo=1 only sets warranty bit if used with over_voltage. And only on some Pi models (not Pi4).
There should be no increase in chance of corrupting sdcard with initial_turbo (or force_turbo), as long as your overclock settings are stable.
I was not aware Pi4 didn't have the warranty bit.
Yes, that is the key, a stable overclock. One persons stable overclock isn't always the same as the next persons. :)
Nathan Scherdin
On Mon, Jun 15, 2020 at 11:17 AM popcornmix [email protected] wrote:
force_turbo=1 only sets warranty bit if used with over_voltage. And only on some Pi models (not Pi4).
There should be no increase in chance of corrupting sdcard with initial_turbo (or force_turbo), as long as your overclock settings are stable.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1375#issuecomment-644291318, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE3QXKJQY7AINJN5RTQQRB3RWZQVBANCNFSM4MMZXIEA .
While the additional 9 seconds might be ok for applications that are just started once and run for eternity, it's a real barrier for portable batterie powered applications with a screen which are meant to be started and shut down.
@popcornmix is the some data what the pi is doing during this time? any way to speed it up?
Setting initial_turbo or using a faster sdcard are the obvious ways of speeding it up.
Connecting a uart and enabling bootloader and/or firmware logging may provide some information about what is happening.
Note that enabling UART logging will slow things down even more, but it might give an idea of where the time is going.
The bootloader is about 3.5 seconds. About 2 seconds are SDRAM init and the reset depends on which start.elf variant is used.
A USB 3.0 pen drive seems to be the best balance between throughput and initialisation time and should be faster than the SD card driver when loading the kernel.
Sorry but my own experiments indicate this delay is happening before reading any significant data from the SD card. I have a kernel mode driver that displays a Splash screen using Dispmanx. It runs, according to "dmesg" at about 1.5 seconds during the boot sequence. In actual fact it runs at 9 seconds from power being applied to the Pi4.
This would indicate no significant SD card reading is occurring during this period. I suspect this delay is in while reading the boot eeprom and executing whatever it is executing.
Note I tested with initial_turbo set and it shaved one second of the boot time. See earlier posts.
Nathan Scherdin
On Tue, Jun 16, 2020 at 4:07 AM popcornmix [email protected] wrote:
Setting initial_turbo or using a faster sdcard are the obvious ways of speeding it up. Connecting a uart and enabling bootloader and/or firmware logging may provide some information about what is happening.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1375#issuecomment-644695752, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE3QXKLLZJCDVE554DDEP5TRW5G7XANCNFSM4MMZXIEA .
Could you go into more detail? RPi3 and earlier models started linux boot within a second or so IIRC. Did they not have to do the ram init? Could we skip the ram init or move it into the linux boot sequence?
As leragequit said above, for handheld applications the long delay is very noticeable. This entire time the user has no feedback and they start thinking something is wrong.
Just so you know, I use decent A1 rated SD cards. I use the same SD cards on the RPi3B+ without this significant delay so even the 3.5 seconds doesnt really account for the total delay time. I can run the same splash screen driver on the RPi3B+ and it shows up in 2 to 3 seconds IIRC. So we are looking at a 6 second difference somewhere. 3.5 seconds doesnt cover it all and seems slow itself compared to earlier models.
Based on dmesg and assuming 3.5 seconds to reach linux boot start then I should be seeing a 5 second delay. Still not great but much better than the 9 seconds I'm seeing right now.
Nathan Scherdin
On Tue, Jun 16, 2020 at 4:20 AM Tim Gover [email protected] wrote:
The bootloader is about 3.5 seconds. About 2 seconds are SDRAM init and the reset depends on which start.elf variant is used.
A USB 3.0 pen drive seems to be the best balance between throughput and initialisation time and should be faster than the SD card driver when loading the kernel.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1375#issuecomment-644701289, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE3QXKLM3IP7INTXAW5X3EDRW5IONANCNFSM4MMZXIEA .
Yes
The SD card is (almost) completely irrelevant. My config is:
initial_turbo=10
start_cd=1
arm_64bit=1
gpu_mem=16
disable_splash=1
force_eeprom_read=0
boot_delay=0
#initramfs initram 0x00200000
[pi4]
armstub=armstub8-rpi4.bin
kernel=kernel8-rpi4.img
kernel8-rpi4.img is a bare metal 4kb boot loader which blinks on very start. It takes 5s from powering up the rpi4 to this blink.
If I uncomment initramfs it will load additional 200kb of data in marginally longer time.
Boot partion uses very small clusters (one sector) it helps if it is cleared (backup first) by:
mkfs.fat /dev/sdb1 -n boot -F 32
and files are copied in one go (won't be fragmented that way)
@pelwell I suppose training sequence can't be cached :) ? oh well... I bought the device for computing power anyway (but my use case consist fast boot up too - so any improvement is most welcome) Thanks for wonderful device!
@Yoshqu there is a much simpler way to measure boot time to the usec, without having to use that custom bootloader https://gist.github.com/cleverca22/58784f67690bfb97492f3f439ff00ed7
basically, ST_CLO begins counting at 1mhz, the instant the SoC comes out of reset and /proc/uptime begins counting seconds when linux starts up its internal clocks
the code in the gist, will then print both of them at once, and if you find the difference, youll see how long it took for linux to gain control of the core
I dont need to know exactly how long the delay is(within a second like I ahve now seems reasonable. I know it is longer than the 5 second I was told it should be so I'm trying to figure out WHY it is longer. Got any way I can do that? And a way to reduce the time to the 5 seconds perfect boot would also be really appreciated.
Nathan Scherdin
On Wed, Jul 29, 2020 at 10:25 AM Michael Bishop [email protected] wrote:
@Yoshqu https://github.com/Yoshqu there is a much simpler way to measure boot time to the usec, without having to use that custom bootloader https://gist.github.com/cleverca22/58784f67690bfb97492f3f439ff00ed7
basically, ST_CLO begins counting at 1mhz, the instant the SoC comes out of reset and /proc/uptime begins counting seconds when linux starts up its internal clocks
the code in the gist, will then print both of them at once, and if you find the difference, youll see how long it took for linux to gain control of the core
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1375#issuecomment-665795890, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE3QXKJK4Q6NOGRM2E46Y2LR6BLOXANCNFSM4MMZXIEA .
I am experiencing the same issue on the PI4 currently.... I have noticed that when not enabeling 64 bit mode I can reduce the time by almost 1 second, 4 seconds seems to be the sonic barrier here... I would really like to understand why exactly that is...
It's not an issue, it's a fact of life. The memory interface needs to calibrated at boot, and that takes time.
The 32-bit kernel can decompress itself, so is stored compressed on sdcard. The 64-bit kernel doesn't support that so it is a larger file and takes longer to load from sdcard.
Phil Elwell. The 5 seconds is a fact of life , yes. The 9 second delay is not. Or was the 5 seconds to calibrate and get to boot just a ball park and 9 seconds could be perfectly valid till linux even begins to boot?
popcornmix, this is with the 32bit OS.
Nathan Scherdin
On Thu, Jul 30, 2020 at 8:31 AM popcornmix [email protected] wrote:
The 32-bit kernel can decompress itself, so is stored compressed on sdcard. The 64-bit kernel doesn't support that so it is a larger file and takes longer to load from sdcard.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1375#issuecomment-666459624, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE3QXKIFTN56MNLCOQUXTJDR6GG6HANCNFSM4MMZXIEA .
Once the bootloader (i.e. the EEPROM, not the main start*.elf loaders) has loaded the appropriate start*.elf and launched it, it has to load config.txt, the kernel, the dtb, cmdline.txt, apply overlays and other DTB changes, and load any external armstub or dt-blob file. There's also a fair amount of moving things around because it isn't always possible to know up front where to load something to. Most of the hardware devices need to be reinitialised, a HAT EEPROM and POE fan probed for. Boot is essentially sequential and it all adds up.