Booting embedded Linux in 0.37 seconds on an ARMv7-A CPU at 528 MHz (opens in new tab)

- Having a HDD connected to the additional SATA ports provided by an onboard controller (not the chipset) incurred a delay because the controller was initialized later (slower?), the HDD would power up later, and the POST sequence wouldn't finish until the HDD finished spinning up. Checking SMART on boot just made it worse.

- Switching between the 2 GPUs I had available at the time (one Nvidia, one AMD) consistently made a couple of seconds of difference.

- Using XMP made POST much slower too (don't remember by how much).

- Updating the FW on my SSD shaved a bit of time.

- Devices connected to USB during post also increased POST time.

And as a side note, my cheaper, simpler mobos would always POST faster. Gaming/OC mobos these days are loaded and it all adds up to what the PC has to do to initialize in POST.

Bottom line is it's easier to optimize for short POST when your config is locked in place (like a phone) then on a machine that could have any number of possible permutations of hardware and settings. Today that's x86.

I'm pretty sure I've seen worse, but in fairness you can only check 1T of RAM so fast:) (These were monster database servers.)

I have an old car (with a modern <2 year old battery BTW) sitting in the driveway that rarely gets driven. For a long time, every time I wanted to drive the car the battery charge would be so low it would fail to crank the engine enough to start it. I would jump-start it and drive it for at least an hour, and if I would drive it again within a week or two it would be fine, but after ~3 to ~4 weeks the battery would be dead again.

When I finally got around to diagnose the problem and measured leak current while removing the fuses 1-by-1, I found out that the tiny light in the glovebox compartment was not turning off because the lid switch did not engage properly. The current was something like 100 mAh but it was apparently enough to drain a less-than-full battery within only a few weeks...

Which is also somewhat annoying because it completely trashes portability, which can be really irritating in cloud environments.

Ubuntu has similar capability (and I'm guessing Debian upstream?), but you have to specifically enable it, by default it ships the full modules set in the initramfs.

I would imagine most places outside of embedded world and maybe microvms, this stuff isn't that valuable.

That still shouldn't take that long, though, should it? 3s sounds like some O(N^2) process is happening.

Keep in mind that this stuff is happening close to the metal, on a nowadays-unshared medium (no Ethernet hubs around any more), with negligible speed-of-light delays because the nearest switch is probably ~100ft away at most. If some high-level protocol like Steam Link can have no perceivable latency, then certainly PHY negotiation shouldn't.

My naive guess would be that the medium is speed-tested in order, first seeing if it works at 1Mbps, then 10Mbps, then 100Mbps, and finally 1Gbps; and alternating in the crossover-cable versions of those tests; satisficing with the last-achieved line rate when the next up-clocking fails.

If that's the case, then I have a feeling that modern hardware could get a bit of an advantage just from doing things in the opposite order: 1. optimistically assuming everything is set up for 1Gbps, and then, if not, ratcheting down the link-speed until the link starts working; and 2. only doing the crossover-cable tests after all the non-crossover tests fail.

You'd still have the same worst-case performance (3s) as before, but now that worst-case would be for old 1Mbps crossover cables: not a common case!

You can use http://bugmenot.com/view/jedec.org to get free-to-use credentials.

The section in point is "A.6.1Bus initialization".

I'd say that if your MMC works fine going full-speed out of the gate and the IC on the board supports this speed, then you unlikely to encounter any issues.