Kernel boot time

[shenki]

The BMC kernel takes about 9 seconds to start on a Romulus machine. The three biggest chunks come from these init calls:

• populate_rootfs
• aspeed_smc
• of_platform_serial_driver_init

We should see if these can be reduced.

[legoater]

The SPI read timing calibration takes some cycles :

[    3.030827] aspeed-smc 1e620000.flash-controller: Using 50 MHz SPI frequency
[    3.038021] aspeed-smc 1e620000.flash-controller: control register: 000b0641
[    3.038042] aspeed-smc 1e620000.flash-controller: control register changed to: 00000600
[    3.038056] aspeed-smc 1e620000.flash-controller: default control register: 00000600
[    3.038170] aspeed-smc 1e620000.flash-controller: w25q256 (32768 Kbytes)
[    3.044901] aspeed-smc 1e620000.flash-controller: CE0 window [ 0x20000000 - 0x22000000 ] 32MB
[    3.053545] aspeed-smc 1e620000.flash-controller: CE1 window [ 0x22000000 - 0x2a000000 ] 128MB
[    3.062176] aspeed-smc 1e620000.flash-controller: write control register: 00020602
[    3.062194] aspeed-smc 1e620000.flash-controller: read control register: 203b0641
[    3.069683] aspeed-smc 1e620000.flash-controller: AHB frequency: 198 MHz
[    3.094912] aspeed-smc 1e620000.flash-controller: Trying HCLK/5...
[    3.176106] aspeed-smc 1e620000.flash-controller:   * [00080000] 0 HCLK delay, 4ns DI delay : PASS
[    3.257181] aspeed-smc 1e620000.flash-controller:   * [00000000] 0 HCLK delay, 0ns DI delay : PASS
[    3.338348] aspeed-smc 1e620000.flash-controller:   * [00090000] 1 HCLK delay, 4ns DI delay : PASS
[    3.338372] aspeed-smc 1e620000.flash-controller:  * -> good is pass 1 [0x00000000]
[    3.338386] aspeed-smc 1e620000.flash-controller: Trying HCLK/4...
[    3.406004] aspeed-smc 1e620000.flash-controller:   * [00008000] 0 HCLK delay, 4ns DI delay : PASS
[    3.473986] aspeed-smc 1e620000.flash-controller:   * [00000000] 0 HCLK delay, 0ns DI delay : PASS
[    3.542161] aspeed-smc 1e620000.flash-controller:   * [00009000] 1 HCLK delay, 4ns DI delay : PASS
[    3.542184] aspeed-smc 1e620000.flash-controller:  * -> good is pass 1 [0x00000000]
[    3.542203] aspeed-smc 1e620000.flash-controller: Found good read timings at HCLK/4
[    3.547603] 5 fixed-partitions partitions found on MTD device bmc
[    3.553713] Creating 5 MTD partitions on "bmc":
[    3.558256] 0x000000000000-0x000000060000 : "u-boot"
....

[mdmillerii]

The time spent in populate_rootfs is the time taken to unpack the compressed initramfs file system.

The compression method was chosen to minimize the on-flash size. Other options may require less time to unpack.

Converting the shell script to C would be another alternative (some would probably like the elimination of the shell), and the dedicated binary should take a lot less space than the full busybox binary without sacrificing function. (The development features could then be compiled out).

As a less drastic option, one could try to minimize the busybox config to only include the commands used by the init, update, and reboot scripts. We could explore static linking (eg we don't need external mtd tools for ubi commands).

Another thought is to eliminate the need for the initramfs stage by directly mounting the squashfs root file system from the mtd similar to what we do with witherspoon and the ubi-fs option. This would require splitting out the feature into "mostly-readonly just var and etc in the overlayfs" from the ubi-fs distro feature, and then finding an alternative method for prepare-to-update-flash to run from ram. If we go back and enable the ramdisk block devices we could just load the root squashfs mtd partition as the initramfs and mount it using root=/dev/ram0 for update mode (although the kernel would end up copying the data 3 times, it would not involve decompression).