Hi Paul, I am also trying to make my PocketBeagle startup time faster and after disabling a lot of scripts I saw little progress until I disabled bonescript-autorun.service
sudo systemctl disable bonescript-autorun.service You don’t see it when you run 'systemd-analyze blame' but look at the output of 'systemctl status' It is the default Web server and the one that gives you all the info on the BeagleBone when you just start with it. If you are not just starting with the board you probably don't need it. My startup time dropped about 14 seconds. (4.19.94-bone44) *Before:* *Startup finished in 7.003s (kernel) + 40.578s (userspace) = 47.581s * *After:* *Startup finished in 6.781s (kernel) + 26.379s (userspace) = 33.161s* (in reality about 42 seconds from the power button push to my wireless network being connected and my program spewing data to the computer.) See below my message for the complete output of systemd-analyze TJF mentioned even better boot times by disabling the universal cape. I tried this line once: cape_universal=disable But ended up with an unresponsive board... (PocketBeagle) I am still wondering what the generic universal-cape line does in uEnv.txt. I have now used: enable_uboot_cape_universal=0 enable_uboot_cape_universal=1 #enable_uboot_cape_universal=1 And there is no difference at all in the boot time. Is there a way to check if it is active? When I disable [email protected] my boot time reduces again with 14s: *Startup finished in 6.726s (kernel) + 12.957s (userspace) = 19.684s * The service is recreated though at the next boot. And the actual start time of the board (time to wifi connection from button push) still stays at about 40 seconds. I wonder if the extra time is actually the Wifi USB dongle starting up. dmesg output: [ 19.595409] usb 1-1: Manufacturer: Realtek [ 19.595416] usb 1-1: SerialNumber: 123456 [ 33.475816] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 33.490036] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 34.111534] RTW*: module init start* Then this thread <https://www.raspberrypi.org/forums/viewtopic.php?t=200385> seemed interesting to me. It is about the raspberry PI but the question posed is if it is possible to start systemd-timesyncd.service later from Kosi: *"So we should rather stay with fake-hwclock for saving/loading last system time on boot before systemd-fsck-root.service and use systemd-timesyncd.service for network time synchronization only?* *Then it could be better to change systemd-timesyncd.service dependencies to load after network-online.target only to save some time during the boot.* Code: Select all <https://www.raspberrypi.org/forums/viewtopic.php?t=200385#> [Unit] DefaultDependencies=no #After=systemd-remount-fs.service systemd-sysusers.service #Before=time-sync.target sysinit.target shutdown.target After=network-online.target Before=shutdown.target Conflicts=shutdown.target #Wants=time-sync.target ... [Install] #WantedBy=sysinit.target WantedBy=multi-user.target Best, Hans. My complete 'system-analyze blame' before and after I disabled the bonescript-autorun.service and finally disabling the [email protected] Before: *debian@beaglebone*:*~*$ systemd-analyze Startup finished in 6.801s (kernel) + 39.999s (userspace) = 46.800s multi-user.target reached after 39.558s in userspace *debian@beaglebone*:*~*$ systemd-analyze blame 32.964s generic-board-startup.service 23.167s dev-mmcblk0p1.device 2.500s systemd-udev-trigger.service 1.805s networking.service 1.345s avahi-daemon.service 1.316s ssh.service 1.209s dnsmasq.service 1.118s systemd-timesyncd.service 1.115s systemd-logind.service 1.113s connman.service 1.051s systemd-journald.service 1.003s libpruio-lkm.service 720ms wpa_supplicant.service 626ms systemd-update-utmp.service 597ms rsyslog.service 588ms systemd-user-sessions.service 478ms systemd-remount-fs.service 472ms [email protected] 466ms fake-hwclock.service 451ms dev-mqueue.mount 439ms systemd-modules-load.service 412ms systemd-tmpfiles-setup.service 378ms systemd-sysctl.service 355ms kmod-static-nodes.service 352ms systemd-journal-flush.service 351ms systemd-update-utmp-runlevel.service 337ms systemd-sysusers.service 328ms systemd-udevd.service 328ms systemd-tmpfiles-setup-dev.service 325ms sys-fs-fuse-connections.mount 317ms systemd-rfkill.service 303ms sys-kernel-debug.mount 275ms systemd-random-seed.service 229ms sys-kernel-config.mount 164ms ifupdown-pre.service 117ms [email protected] 86ms cloud9.service After: *debian@beaglebone*:*~*$ systemd-analyze blame 19.139s generic-board-startup.service 17.197s dev-mmcblk0p1.device 2.501s systemd-udev-trigger.service 1.946s networking.service 1.205s systemd-timesyncd.service 1.098s systemd-logind.service 1.019s ssh.service 1.018s systemd-journald.service 970ms libpruio-lkm.service 947ms connman.service 798ms dnsmasq.service 641ms rsyslog.service 620ms avahi-daemon.service 599ms systemd-remount-fs.service 569ms fake-hwclock.service 542ms systemd-update-utmp.service 488ms [email protected] 464ms wpa_supplicant.service 443ms kmod-static-nodes.service 436ms systemd-user-sessions.service 416ms sys-kernel-debug.mount 383ms systemd-tmpfiles-setup.service 381ms systemd-modules-load.service 367ms sys-fs-fuse-connections.mount 354ms systemd-journal-flush.service 350ms dev-mqueue.mount 348ms systemd-udevd.service 338ms systemd-sysusers.service 314ms systemd-tmpfiles-setup-dev.service 303ms systemd-random-seed.service 299ms systemd-rfkill.service 292ms systemd-sysctl.service 225ms sys-kernel-config.mount 197ms systemd-update-utmp-runlevel.service 112ms [email protected] 98ms ifupdown-pre.service 85ms cloud9.service With [email protected] disabled (but still 40 seconds till wifi connection from button push and not disabling service is not permanent) *debian@beaglebone*:*~*$ systemd-analyze blame 17.496s dev-mmcblk0p1.device 5.989s generic-board-startup.service 2.451s systemd-udev-trigger.service 1.849s networking.service 1.189s systemd-timesyncd.service 1.092s connman.service 1.027s ssh.service 1.023s systemd-journald.service 1.015s systemd-logind.service 906ms libpruio-lkm.service 890ms dnsmasq.service 735ms wpa_supplicant.service 719ms avahi-daemon.service 559ms systemd-update-utmp.service 551ms systemd-remount-fs.service 515ms [email protected] 508ms systemd-user-sessions.service 448ms systemd-modules-load.service 448ms kmod-static-nodes.service 407ms dev-mqueue.mount 393ms systemd-tmpfiles-setup.service 392ms rsyslog.service 359ms systemd-journal-flush.service 340ms systemd-udevd.service 331ms sys-kernel-config.mount 326ms systemd-sysusers.service 318ms systemd-sysctl.service 315ms systemd-tmpfiles-setup-dev.service 308ms sys-kernel-debug.mount 298ms systemd-rfkill.service 294ms systemd-random-seed.service 285ms systemd-update-utmp-runlevel.service 257ms sys-fs-fuse-connections.mount 251ms fake-hwclock.service 114ms [email protected] 107ms ifupdown-pre.service 92ms cloud9.service Op zaterdag 25 april 2020 22:07:01 UTC+2 schreef Paul Beam: > > The newest image is certainly an improvement, but my results are not quite >> what yours are. Two quick questions: > > > 1. Is the dev-mmcblk0p1.device time affected by SD card speed? I'm at a > loss why mine is 8 seconds slower than yours. > 2. Is there a way to identify the time consuming parts > generic-board-startup.service? > > Here is where I stand: > systemd-analyze blame > 36.337s generic-board-startup.service > 27.260s dev-mmcblk0p1.device > 3.565s nginx.service > 3.326s loadcpufreq.service > 3.247s systemd-udev-trigger.service > 2.083s networking.service > 1.979s ssh.service > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/5e8d0c8c-bb60-44d5-a094-9b582d4a5616%40googlegroups.com.
