I have a STM32MP157A-DK1 board here, and here's the bootup sequence, with timestamps relative to the first message from uboot:
* uboot start (0s)
* uboot message "Boot over mmc0!" (5s)
* uImage & dtb loaded into memory from sdcard (9s)
* kernel finished, first userland/systemd message (13s)
* systemd runlevel transition finished (32s)
There's probably speedup tweaks that can be made in every stage here but even uboot is going to be a problem in your goal of 2 seconds. To the concerns about PCI enumeration, the STM32MP157A doesn't have any PCI devices or PCI/PCIe connectors.
Thank you!
This means that uboot takes 5 seconds, initramfs loading 4 seconds, kernel boot 4 seconds, and systemd-based userland boot 20 seconds.
The latest takes so long because userland bootup uses lots of random-access 4k reads, and those are the slowest kind; the I/O throughput using random-access 4k reads can be as low as just a couple of megabytes per second, even on devices that can read at 100 Mb/s at 1M and larger continuous chunks.
SD card is just not good enough for minimum boot times.
Userland can easily be stripped down, but there isn't much one can do to uboot and initramfs loading times. The kernel boot time can probably be reduced by using built-in drivers and baked-in dtb. The end result, say 11 to 13 seconds, is what you can expect a wakeup from hibernation (suspend-to-disk) to take, too.
Getting below 12 second boot time from powerup to active services in Linux, seems unlikely or impossible on this particular hardware combination.
Note that by the time the Linux kernel boot completes, it can immediately enumerate itself as an USB device; the userspace does not need to be fully booted up for that.
A faster storage medium for an uncompressed initramfs image could help quite a bit.
Note, however, that the STM32MP157
A is the no-crypto variant; so the above timings do not include any overhead from TF-A or encryption.
Let's review the
STM32MP1 boot sequence.
The 128k Flash on the ST32MP157C or ST32MP157F contains the TF-A (Trusted Firmware-A) first-stage bootloader. (The other variants do not support secure boot or TF-A). This will set up clocks, RAM, et cetera, and load and verify the second-stage bootloader, uboot, from the mass storage, and hand off control to uboot.
uboot will do what it is configured to do, and load the Linux initramfs or kernel+dts from the mass storage, and hand off control to the Linux kernel.
The Linux kernel will configure all peripherals according to dts and probing, then mount the root filesystem (or initramfs), and start userspace init. At this point, the kernel (USB gadget driver) will be active, and can do USB device enumeration; so for OP, this point in time is the target two seconds from powerup.
If an initramfs is used, and there is a separate root partition, a
pivot is done in the userspace initramfs image to swap the initramfs and the newly mounted real root filesystem, then the init continues on the new root filesystem. (This is also why
/etc should always be part of the root filesystem, and not a separate filesystem.)
Looking at the
STM32MP157C datasheet, there are quite a few boot media options. eMMC (4.0 - 4.51) on SDMMC2 seems an obvious choice, and the datasheet claims up to 208 Mbytes/second in 8-bit mode. Practical data rates will be less than that, but will depend heavily on the particular eMMC module chosen. (Note that this applies even if an RTOS is used instead of uboot and/or Linux kernel.)
The question is, what kind of boot times should this yield?
This post at ST Community describes practical OpenSSL AES-128-CBC at 256 byte blocks at around 10 Mbytes/second, which worries me: compare that to the almost 200 Mbytes/second one could expect from eMMC. Even an SD card should yield better than 10 Mbytes/second transfer rates, which indicates a secure boot might be constrained by the encryption rate the STM32MP157C/F is capable of.
I suspect that regardless of the storage media speed, with secure boot and TF-A, the boot times reported by ddrown using an SD card with no crypto would be comparable; i.e. somewhere around ten second boot time, even with a fully optimized Linux userspace or wakeup-from-hibernation. With eMMC and no crypto, I suspect the boot time could be shrunk to somewhere around four seconds or so. These are guesstimates based on playing with a number of Linux SBCs supporting different boot media, however, so basically pulled out of my hat.
With an RTOS, one would replace everything from the second-stage bootloader onwards. The two second time budget includes both TF-A –– remember, ddrown's timings use a variant with no crypto, so we do not actually know how long TF-A takes –– and the RTOS boot-up timing, but I believe an RTOS (without uboot) should be able to enumerate itself as an USB device within the two second time limit from powerup, and be fully functional soon enough after that.