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.

[6by9]

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.

[pelwell]

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.

[timg236]

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.

[pelwell]

An explicit kernel=... and device_tree=... will also bypass any form of searching.

[acidtech]

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.

[pelwell]

intial_turbo=30

There's a typo in this line. It might not have a big effect, but correctly spelt it might have some.

[acidtech]

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 notifications@github.com 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 .

[6by9]

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

[pelwell]

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.

[acidtech]

Ill try it out. Thanks for the suggestion.

Nathan Scherdin

On Wed, Apr 22, 2020 at 2:49 AM Phil Elwell notifications@github.com 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 .

[leragequit]

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

[acidtech]

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 notifications@github.com 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 .

[popcornmix]

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

[acidtech]

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 notifications@github.com 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 .

[popcornmix]

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.

[acidtech]

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 notifications@github.com 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 .

[leragequit]

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?

[popcornmix]

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.

[pelwell]

Note that enabling UART logging will slow things down even more, but it might give an idea of where the time is going.

[timg236]

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.

[acidtech]

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 notifications@github.com 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 .

[acidtech]

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 notifications@github.com 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 .

[Yoshqu]

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!

[cleverca22]

@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

[acidtech]

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 notifications@github.com 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 .

[s00500]

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

[pelwell]

It's not an issue, it's a fact of life. The memory interface needs to calibrated at boot, and that takes time.

[popcornmix]

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.

[acidtech]

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 notifications@github.com 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 .

[pelwell]

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.

[acidtech]

Yes. I am quite aware of how booting works in general and the sequence on the Pi. I am also aware how long it takes to do ALL of that on a Pi3B+. So you are telling me it takes 4 more seconds to do all that on a PI4? And yet a Pi3B+ does the same things(far enough to get a screen) in about 1 second? Really? Really?

Give me a 6 second to something on the screen boot and I'll be happy.

Put a device in front of a user, turn it on and watch their reaction when it takes 9 seconds for anything to happen. At about 7 or 8 seconds they are turning the power switch off and on again because they think something is wrong.

We have added a cycling LED to our product to at least give some feedback while booting but if you have any opportunity to fix this then please do so.

Nathan Scherdin

On Thu, Jul 30, 2020 at 9:37 AM Phil Elwell notifications@github.com wrote:

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.

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

[timg236]

I've just measured the latest release build of the bootloader and power-on to the first instruction in start.elf takes about 3.3 seconds. It's then about 4 seconds in start.elf until the kernel is started, as @pelwell says there's a lot going on before Kernel load. Major changes to the file-system in start.elf are unlikely in the short term.

[acidtech]

Please note I said as soon as possible. If you really absolutely can't get to a DPI display any faster then fine.

BUT continuing to give excuses as to why things are taking so long when you produce a product that obviously doesn't have those same massive delays(eg PI3B) is pointless. I know the Pi3b doesn't have the memory calibration delay but every single other thing Phil Elwell said the Pi4 is doing at boot the Pi3 is also doing at boot. The Pi3b, in an otherwise identical system, boots to Rainbow in 1 second. Add in the 5 seconds for memory calibration and I should be seeing something at 6 seconds. That's all I want. Something on screen to indicate the system is alive.

Do I expect you to jump in and work on this instantaneously, no I dont. I hope you will but I dont expect it. Note the original date I posted this ticket and note I just reply when someone posts to the thread.

Nathan Scherdin

On Thu, Jul 30, 2020 at 10:04 AM Tim Gover notifications@github.com wrote:

I've just measured the latest release build of the bootloader and power-on to the first instruction in start.elf takes about 3.3 seconds. It's then about 4 seconds in start.elf until the kernel is started, as @pelwell https://github.com/pelwell says there's a lot going on before Kernel load. Major changes to the file-system in start.elf are unlikely in the short term.

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

[pelwell]

I'm going to sprinkle a few trace statements in strategic places to get a rough idea of the breakdown.

[acidtech]

Thank you.

Nathan Scherdin

On Thu, Jul 30, 2020 at 10:28 AM Phil Elwell notifications@github.com wrote:

I'm going to sprinkle a few trace statements in strategic places to get a rough idea of the breakdown.

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

[pelwell]

In an unscientific single run, Pi 3B starts the arm at 4.1 seconds, 3B+ at 4.5 seconds and 4B at 8.1 seconds. This is with the timer started by the bootloader EEPROM on 4B, so that extra ~3.5 seconds is the 3.5 @timg236 mentioned.

I have a more detailed breakdown that suggests there are some areas that could be improved, but the differences from 3B to 4B are as expected.

[acidtech]

lets simplify.

How does the Pi3B know I have a DPI LCD? Reading the SD card right? This I assume is being done by the VC4 processor, right? It obviously does this within 1 second since I get the rainbow screen 1 second after power up on my DPI LCD. Right?

I guess the real question from the begining is why can't I get the rainbow screen(or some kind of splash screen) on a Pi4 the same way(eg via the VC6 processor)?

Nathan Scherdin

On Thu, Jul 30, 2020 at 11:08 AM Phil Elwell notifications@github.com wrote:

In an unscientific single run, Pi 3B starts the arm at 4.1 seconds, 3B+ at 4.5 seconds and 4B at 8.1 seconds. This is with the timer started by the bootloader EEPROM on 4B, so that extra ~3.5 seconds is the 3.5 @timg236 https://github.com/timg236 mentioned.

I have a more detailed breakdown that suggests there are some areas that could be improved, but the differences from 3B to 4B are as expected.

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

[JamesH65]

Same process for Pi3 and Pi4. start.elf loads. Loads config.txt entries. Starts going through it startup. If config says there is a DPI screen attached it will initialise the DPI hardware. The firmware cannot autodetect a DPI attached screen. It can autodetect a DSI display. Once all the displays are identified and the required HW started, it loops through and puts the rainbow screen on all displays. This process is the same for the Pi3 and the pi4.

[pelwell]

The next firmware release should provide a useful reduction in boot time.

[acidtech]

James, that makes NO sense. Pi3B rainbow on a DPI LCD in 1 second. Pi4 rainbow on a DPI LCD in 9 seconds. They are the same? I am still confused on what the Pi4 is doing all that time then. I was under the impression the Rainbow was put on by the VC processor? I also understand it takes around 5 seconds for the Pi4 to calibrate RAM timings. I assume it has to do that before the VC processor can do its config.txt/rainbow display duties. But that would be 9-5 seconds = 4 second while the Pi3 does the same thing in 1 second. Do you see my confusion when you tell me my eyes are lying to me?

Phil, thank you. Every little bit helps.

Nathan Scherdin

On Fri, Jul 31, 2020 at 8:38 AM Phil Elwell notifications@github.com wrote:

The next firmware release should provide a useful reduction in boot time.

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

[JamesH65]

Sorry, I was under the impression you wanted to know how it worked, from the person who wrote some of the display code that actually draws the rainbow screen up. Since you appear to only want to whine, you'll get no further help from me.

[popcornmix]

rpi-update firmware should reduce boot time by ~1.7 seconds on Pi4.

[acidtech]

I apologize if I was harsh. But I believe you misread my question. This thread has gotten long so that is probably why. My original question WAS about the delay in general and the reasons for it. But it has narrowed down to just WHY there is nothing on the screen for 9 seconds on a Pi4 but there is on a Pi3B in 1 second.

Everything you answered in your previous response was after effectively after the Pi3B has already displayed the Rainbow on the screen which is why I got snarky. Please note when I first started this issue. It has been a long time. So I do appreciate you looking at it again since It appeared to be dead but I think the problem is miscommunciation of the problem. So I will restate my question again.

Why is the Pi3B Rainbows display(on a DPI LCD) in 1 second from power on, while a PI4 does not display anything for at least 9 seconds on that same DPI LCD? And can this be changed.

Lastly this is NOT about ME. I dont care about the 9 seconds because I know about it. I know to wait. But other users DO NOT. They think something has gone wrong. That I think should be the focus, not me or if I'm whining too much.

Nathan Scherdin

On Fri, Jul 31, 2020 at 8:56 AM James Hughes notifications@github.com wrote:

Sorry, I was under the impression you wanted to know how it worked, from the person who wrote some of the display code that actually draws the rainbow screen up. Since you appear to only want to whine, you'll get no further help from me.

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

[timg236]

Slightly off-topic but you to want to consider adding USB_MSD_PWR_OFF_TIME=0 to the EEPROM config because of this pending change which is unfortunately necessary in order to resolve USB failures with some devices after a reboot. https://github.com/raspberrypi/linux/issues/3334 https://github.com/raspberrypi/rpi-eeprom/commit/d7b1a49a8356b09384817d362cbfb572e50770a8

[acidtech]

We only use cold start. No reboots. Does this still effect it?

Nathan Scherdin

On Fri, Jul 31, 2020 at 10:01 AM Tim Gover notifications@github.com wrote:

Slightly off-topic but you to want to consider adding USB_MSD_PWR_OFF_TIME=0 to the EEPROM config because of this pending change which is unfortunately necessary in order to resolve USB failures with some devices after a reboot. raspberrypi/linux#3334 https://github.com/raspberrypi/linux/issues/3334 raspberrypi/rpi-eeprom@d7b1a49 https://github.com/raspberrypi/rpi-eeprom/commit/d7b1a49a8356b09384817d362cbfb572e50770a8

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

[timg236]

It does at the moment, there's an awkward case where the PMIC reset for SD voltage reset off could look like a cold reset but still potentially cause the problem with USB devices. So that's a future optimization.

If you are only doing cold-starts then it should be safe to always have USB_MSD_PWR_OFF_TIME=0 in the config. Some industrial customers use the hooks mechanism in /usr/bin/rpi-eeprom-update where they want EEPROM updates but need to force certain settings (e.g. WAKE_ON_GPIO etc)

[acidtech]

Thank you for the details. I will look into use the hooks.

Nathan Scherdin

On Fri, Jul 31, 2020 at 10:40 AM Tim Gover notifications@github.com wrote:

It does at the moment, there's an awkward case where the PMIC reset for SD voltage reset off could look like a cold reset but still potentially cause the problem with USB devices. So that's a future optimization.

If you are only doing cold-starts then it should be safe to always have USB_MSD_PWR_OFF_TIME=0 in the config. Some industrial customers use the hooks mechanism in /usr/bin/rpi-eeprom-update where they want EEPROM updates but need to force certain settings (e.g. WAKE_ON_GPIO etc)

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

[s00500]

I can confirm an improvement using the rpi-update firmware @popcornmix thanks

[lurch]

Also regarding the differences between the 3B+ and 4B bootup process - the bootloader on the Pi 3B+ is baked into the SoC itself, whereas on the Pi4B it has to load the bootloader from EEPROM (although I have no idea how much overhead this adds).

[RomanValov]

@popcornmix Is it possible that changes made lead to rainbow splash is not shown anymore (even if explicitly configured to)? My boot config has lines:

boot_delay=3
boot_delay_ms=0
disable_splash=0

and I still do not get rainbow splash shown on boot up.

It has been broken since commit.