4 ms·

The bootloader's driver for your storage device is often very simplistic. Eg: it might only read one sector at a time, might not have the FAT cached in RAM, etc

The bootloader's driver for your storage device is often very simplistic. Eg: it might only read one sector at a time, might not have the FAT cached in RAM, etc. It is not designed for speed - only for simplicity and size. So, reading a few MB fewer from storage is often actual time savings. Plus there are things like [e]MMC's "boot" area, where a special storage area is simpler to read using a simpler special protocol. That area has a limited size.

jandrese 6y ago
What kind of time savings are we talking about for 7 megabytes here? A second? Three seconds? Or is it more like 20ms? Is it still common to source components from 1995 in these devices?
- setpatchaddress 6y ago
  20ms is a long time in low-level systems programming, especially where concurrency might be low or limited. You only need to find five 20ms savings opportunities to shave a tenth of a second off of your boot time. Edited to add: A lot of performance loss for large, complex systems is death-by-a-thousand-cuts -- 20ms here and there can make a real, user-perceivable difference.
- MartijnBraam 6y ago
  In case of the PinePhone (which is arm64) the actual loading of the kernel image from eMMC can take a second because the MMC controller isn't initialized for max speed by the bootloader, so having a smaller kernel saves some time between pressing the power button and having the splash screen show up (since the bootloader can't control the display)
  - megous 6y ago
    U-Boot can absolutely use the max speed. Just apply some mmc patches from here: https://megous.com/git/u-boot/log/?h=opi-v2020.04 https://megous.com/git/u-boot/log/?h=opi-v2020.04
    - voltagex_ 6y ago
      Do you think those patches will be upstreamed?
      - megous 6y ago
        If someone does it, then yes, otherwise I don't plan to do it myself.
- tkln 6y ago
  I don't have exact numbers on this any more. It's been couple of years since I last worked in embedded storage and boot optimization. When optimizing boot time of an embedded system something like 100 ms is a significant saving once you've picked all the low hanging fruit in the user space init side. In the end, every millisecond counts as it all adds up when there are hundred or so places where they may end up being spent needlesly. An embedded product, especially automotive, might have rather strict boot time requirements. The time it takes for a bootloader to load a kernel image can be a decent part of the boot time. The bootloader most likely won't be running the SDHCI controller in any of the faster modes that require implementing bus training, calibration, and tuning algorithms of varying complexity.
- megous 6y ago
  Usual unoptimized speed may be ~23MiB/s for SD card for example.
- voltagex_ 6y ago
  Slightly off topic: the last time I saw stuff about speeding up boot of small devices was here - https://megous.com/git/p-boot/about/ https://megous.com/git/p-boot/about/

jandrese 6y ago

What kind of time savings are we talking about for 7 megabytes here? A second? Three seconds? Or is it more like 20ms? Is it still common to source components from 1995 in these devices?

setpatchaddress 6y ago
20ms is a long time in low-level systems programming, especially where concurrency might be low or limited. You only need to find five 20ms savings opportunities to shave a tenth of a second off of your boot time. Edited to add: A lot of performance loss for large, complex systems is death-by-a-thousand-cuts -- 20ms here and there can make a real, user-perceivable difference.
MartijnBraam 6y ago
In case of the PinePhone (which is arm64) the actual loading of the kernel image from eMMC can take a second because the MMC controller isn't initialized for max speed by the bootloader, so having a smaller kernel saves some time between pressing the power button and having the splash screen show up (since the bootloader can't control the display)
- megous 6y ago
  U-Boot can absolutely use the max speed. Just apply some mmc patches from here: https://megous.com/git/u-boot/log/?h=opi-v2020.04 https://megous.com/git/u-boot/log/?h=opi-v2020.04
  - voltagex_ 6y ago
    Do you think those patches will be upstreamed?
    - megous 6y ago
      If someone does it, then yes, otherwise I don't plan to do it myself.
tkln 6y ago
I don't have exact numbers on this any more. It's been couple of years since I last worked in embedded storage and boot optimization. When optimizing boot time of an embedded system something like 100 ms is a significant saving once you've picked all the low hanging fruit in the user space init side. In the end, every millisecond counts as it all adds up when there are hundred or so places where they may end up being spent needlesly. An embedded product, especially automotive, might have rather strict boot time requirements. The time it takes for a bootloader to load a kernel image can be a decent part of the boot time. The bootloader most likely won't be running the SDHCI controller in any of the faster modes that require implementing bus training, calibration, and tuning algorithms of varying complexity.
megous 6y ago
Usual unoptimized speed may be ~23MiB/s for SD card for example.
voltagex_ 6y ago
Slightly off topic: the last time I saw stuff about speeding up boot of small devices was here - https://megous.com/git/p-boot/about/ https://megous.com/git/p-boot/about/