RPi4: Long delay before booting linux after power on

[acidtech]

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.

[timg236]

boot_delay happens very early on during the execution of start.elf an is before display initialization. Recent improvements to boot time have reduced the time between the splash screen being displayed and kernel load. Consequently, it's likely to have removed the splash screen before some monitors have switched resolution.

[franklesniak]

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

Hey @acidtech, slightly off-topic, but is the effect of the [edid=] section that the Parallel Display Interface would be disabled if any* HDMI display is connected? And if no HDMI display is connected, the section is ignored - so the Parallel Display Interface is left configured?

[acidtech]

Correct. The one catch is not all HDMI monitors have valid EDID. So far I have not run into a problem with that but I'm sure there are some incompatible monitors.

This is certainly a lot easier than the old method of running a script and rebooting if HDMI was or wasnt connected so I think it is worth the small chance someone will have an unsupported HDMI monitor.

Nathan Scherdin

On Wed, Dec 30, 2020 at 6:11 PM Frank Lesniak notifications@github.com wrote:

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=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.

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=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.

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=... and device_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.

Hey @acidtech https://github.com/acidtech, slightly off-topic, but is the effect of the [edid=] section that the Parallel Display Interface would be disabled if any* HDMI display is connected? And if no HDMI display is connected, it is ignored?

— 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-752817323, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE3QXKO257EEFKXER7DVIZLSXPMTXANCNFSM4MMZXIEA .

[leragequit]

Hello again,

I have been looking at the boot times again and it seems not much has changed. I am still sitting at 9 second before I see the rainbow screen while building something that is meant to be a portable device at some point. Are there any developments, like new options for the bootloader and config.txt to stop the pi from unecessary processing when the enviroment is very defined? @acidtech did you manage to trim down the time a bit?

Best regards,

Sascha

[lurch]

Have you tried enabling the bootloader UART output? That might give you some idea of what the bootloader is actually doing? https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md

[pelwell]

"sudo vcdbg log msg" is a quicker way to the same information.

[acidtech]

I read something in the new eeprom update that was just released about not displaying the boot screen so long. Would that have any effect on the boot time? I'm currently satisfied with the boot time(eg no customers are complaining :) ) but that may be something to look at.

Nathan Scherdin

On Thu, Apr 22, 2021 at 7:09 AM Phil Elwell @.***> wrote:

"sudo vcdbg log msg" is a quicker way to the same information.

— 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-824875131, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE3QXKPROUXEAGVHB2BYZ73TKAUZ5ANCNFSM4MMZXIEA .

[lurch]

I think the EEPROM changes you refer to are just to make it less likely that the diagnostics screen gets shown before the rainbow screen appears? (i.e. only show the diagnostics screen if there's actually a problem preventing booting.) People sometimes panic if they see "unexpected text" on screen, even if that text is harmless :wink: Shouldn't have any affect on bootup times AFAIK.

[leragequit]

@acidtech what did you get the boot times down to? do you mind sharing settings :D?

[lurch]

@pelwell Just out of curiosity, is it possible that the SDRAM initialisation on a 2GB Pi4B would be fractionally quicker than on an 8GB Pi4B ? :shrug: (or would any difference be imperceptible?)

[pelwell]

There are minor timing between different SDRAM parts, but it's more about the number of dies on the chip than the capacity.

The latest stable EEPROM image is quicker than previous version, but in general there is no work happening (or likely to happen) specifically to reduce boot times - either in the EEPROM or the firmware - so unless an optimisation becomes apparent during other work, the current releases are probably as good as it gets.

[acidtech]

Its at about 7 seconds still, but there is enough indication of booting that no one is complaining. After power stich is turned on we cycle the power led and about 2 seconds later init the LCD(via a separate microcontroller) which causes the screen to go black but with the backlight on. Then the Pis prompt shows up at about 7 seconds. This is enough indication of life for our users.

Nathan Scherdin

On Fri, Apr 23, 2021 at 12:55 AM leragequit @.***> wrote:

@acidtech https://github.com/acidtech what did you get the boot times down to? do you mind sharing settings :D?

— 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-825471210, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE3QXKJA7M6J3KU3DQFLKULTKERYXANCNFSM4MMZXIEA .

[lurch]

I guess if you wanted a more "instant on" behaviour you could use the Raspberry Pi Pico microcontroller? But I've obviously got no idea what your application does so I dunno if that's a workable option for you.

[acidtech]

The original complaint was the boot time difference between other Pis and the PI4. Pi3B+ and earlier models have a boot screen within 2 seconds of power applied. The Pi4 takes 7 to 9 seconds(depending on if initial_turbo is used). That is just long enough that people start unplugging power thinking there is a problem. Our work around was to, 1. cycle our own power LED indicating the unit was booting and 2. init the LCD/backlight a couple seconds after the power LED starts cycling. This provides enough "life" to the system to prevent people from trying to disconnect power thinking there is something wrong.

Nathan Scherdin

On Fri, Apr 23, 2021 at 12:08 PM Andrew Scheller @.***> wrote:

I guess if you wanted a more "instant on" behaviour you could use the Raspberry Pi Pico microcontroller? But I've obviously got no idea what your application does so I dunno if that's a workable option for you.

— 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-825862711, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE3QXKLEOKFVRNK33LBE7SDTKHATTANCNFSM4MMZXIEA .

[tam1111574]

Hello all, Anybody have the way to reduce this time ?..

[hippyau]

I'm trying to get times down too, can anyone confirm if APPEND_DTB to kernel and removing from boot works / helps? Not had any luck booting with an appended 5.10 kernel.

[hippyau]

I have a config.txt as follows. Trying to use a CM4 with eMMC in an industrial project. It needs to come up as soon as possible.

It takes 7 seconds from power-on for the kernel to start, and 3 seconds for the kernel to boot.

Surely there has to be a faster way? Will appending the DTB to the kernel and removing from boot help? Is that possible?

This guy boots a RPI3 in less than 2 seconds?!?! https://www.furkantokac.com/rpi3-fast-boot-less-than-2-seconds/

start_file=start.elf
fixup_file=fixup.dat
kernel=Image
arm_64bit=1
#active cooling required
initial_turbo=15
over_voltage=6
arm_freq=2000

# gpu_mem_256=100
# gpu_mem_512=100
# gpu_mem_1024=100

max_framebuffer_height=1920
hdmi_ignore_edid=0xa5000080
hdmi_timings=480 1 48 32 80 1920 0 3 10 56 0 0 0 60 0 75840000 3
hdmi_group=2
hdmi_mode=87
hdmi_force_mode=1
hdmi_drive=1
config_hdmi_boost=4
display_hdmi_rotate=2

dtparam=i2c_arm=on
#dtparam=audio=on

dtoverlay=vc4-fkms-v3d
max_framebuffers=2

dtoverlay=dwc2,dr_mode=host

dtoverlay=disable-bt

enable_uart=1

init_uart_clock=16000000
dtoverlay=uart0
dtoverlay=uart2
dtoverlay=uart3
dtoverlay=uart4
dtoverlay=uart5

disable_splash=1
boot_delay=0

[Yoshqu]

As it was said in messages above - SDRAM PHY is lengthy (seems around 4s?). It seems as least time for boot loader. With full blown config as yours it will be hard to achieve.

So, comparing RPi3 to RPi4 is comparing apples to oranges.

[hippyau]

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.

@pelwell I understand the start_cd only allows for a small CPU/GPU memory division, is there a way to change that?

[popcornmix]

@pelwell I understand the start_cd only allows for a small CPU/GPU memory division, is there a way to change that?

Why do you want a large gpu memory with the cutdown firmware? The cutdown firmware has basically no firmware services available (so no firmware 3d, no codecs, no camera, no mall/openmax, no submitting firmware vpu/qpu jobs). For what reason do you need the extra gpu memory?

[hippyau]

Ah, thank you. This makes much sense, as it was not clear exactly what was cut down. I need the GPU, and little else, I presumed as it controls the boot process from my understanding, it would be available. I suppose I am poking in the dark for solutions.

[pelwell]

Note that the most recent firmware builds (7208c3d557c7cc95bca06aa917dda1f7db91250c and later) should boot fractionally quicker (~0.8s less).

[hippyau]

Thanks @pelwell, I will give it a go. So surprised by this issue :100:

[lurch]

I dunno if it'll make any noticeable difference, but I might be worth tweaking BOOT_ORDER to only include the boot method that you're actually using? https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md

[tianxun-ng]

Hi, any updates so far? I'm also facing the same issue. The rainbow screen comes out (kernel starts) only after 6 seconds. Previously on CM3Plus the rainbow screen appears within 2 seconds then continue booting the rest of OS.

[JamesH65]

The latest Pi4 does have a longer boot time than earlier models, due to the new network install (1s), plus AVS calibration (0.5s),plus grabbing the edid for second displays. You can get rid of the network boot delay using NET_INSTALL_ENABLED=0 (see https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware/release-notes.md), but there's not a lot that can be done about everything else.

[tianxun-ng]

Thanks. How do I get rid of the network boot delay NET_INSTALL_ENABLED=0? I'm currently using 64-bit Debian 11 (not Raspbian) so there's no tool to update the EEPROM. What else can I disable to make the boot faster other than this option? thanks

[JamesH65]

https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#updating-the-eeprom-configuration

If necessary, get a new SD card, install PiOS and do the work in that. Then go back to Debian.

[faaizrafi]

I'm using Raspberry Pi 4B for about an year now, last week i upgraded my sd card from 8gb to 32gb to get more space on the system. Now the raspi is taking too long to boot. I ran the command [b]systemd-analyze blame[/b] to know which process is taking too long. I have attached the snap below, what should i do?