PocketBeagle Boot Time

[Paul Beam]

Has anyone had success getting the PocketBeagle boot time to less than 30 seconds?  

[TJF]

On BBB:

$ systemd-analyze

Startup finished in 1.067s (kernel) + 15.828s (userspace) = 16.896s

Booting with USB WiFi stick including connection with static IP adress. Should be possible with PocketBeagle as well. Find details at

https://groups.google.com/d/msg/beagleboard/CN5qKSmPIbc/9yNlI-w1AQAJ

[rpau...@gmail.com]

Thanks.  I will look at that thread.  My recent efforts have resulted in negative process. 

Startup finished in 17.476s (kernel) + 41.899s (userspace) = 59.376s

--
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 beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/2a75d9fa-0cfa-4c4c-b29a-98c7a424caeb%40googlegroups.com.

[Daniel Kulp]

The first step would be to delete any initrd images in /boot.   That will likely chop about 10 seconds off the "kernel" time.   I'm not sure why we're creating the initrd things.  

On Sunday, April 19, 2020 at 3:38:00 PM UTC-4, rpau...@gmail.com wrote:

Thanks.  I will look at that thread.  My recent efforts have resulted in negative process. 

Startup finished in 17.476s (kernel) + 41.899s (userspace) = 59.376s

 

From: beagl...@googlegroups.com <beagl...@googlegroups.com> On Behalf Of TJF
Sent: Saturday, April 18, 2020 2:04 PM
To: BeagleBoard <beagl...@googlegroups.com>
Subject: [beagleboard] Re: PocketBeagle Boot Time

 

On BBB:

 

$ systemd-analyze

Startup finished in 1.067s (kernel) + 15.828s (userspace) = 16.896s

 

Booting with USB WiFi stick including connection with static IP adress. Should be possible with PocketBeagle as well. Find details at

 

https://groups.google.com/d/msg/beagleboard/CN5qKSmPIbc/9yNlI-w1AQAJ

 

 

--
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 beagl...@googlegroups.com.

[rpau...@gmail.com]

I have done that, but I am perplexed with the results I posted – I think that was from a different unit as I have several in various states of development.  From what I have read, the usb gadget takes most of the userspace time.  On the one hand, I find it amazing that the startup scripts work for so many boards, but on the other hand I find their size and complexity daunting to tramps through and figure out.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/9de2a436-e717-4cc0-8571-8803f46bfb4d%40googlegroups.com.

[Robert Nelson]

On Thu, Apr 23, 2020 at 7:42 AM <rpau...@gmail.com> wrote:
>
> I have done that, but I am perplexed with the results I posted – I think that was from a different unit as I have several in various states of development. From what I have read, the usb gadget takes most of the userspace time. On the one hand, I find it amazing that the startup scripts work for so many boards, but on the other hand I find their size and complexity daunting to tramps through and figure out.

Hi Paul,

What kernel are you using?

Before our Spring 2020 release time, i had spent some time cleaning up
the boot script (and the kernel..)

Have you tried the newer Spring 2020 "console" image?

https://elinux.org/Beagleboard:Latest-images-testing#Debian_10_.28Buster.29_Console

Out of the box, (2nd boot, as the 1st boot generates the ssh keys..)

debian@beaglebone:~$ uname -r
4.19.94-ti-r42


debian@beaglebone:~$ systemd-analyze
Startup finished in 7.686s (kernel) + 29.068s (userspace) = 36.755s
graphical.target reached after 28.776s in userspace

debian@beaglebone:~$ systemd-analyze blame
21.211s generic-board-startup.service
19.429s dev-mmcblk0p1.device
3.214s systemd-udev-trigger.service
2.649s loadcpufreq.service
1.970s networking.service
1.466s ssh.service
1.387s systemd-logind.service
1.318s systemd-journald.service
1.261s systemd-timesyncd.service
1.135s connman.service
1.077s bb-wl18xx-wlan0.service
835ms dnsmasq.service
707ms cpufrequtils.service
695ms wpa_supplicant.service
644ms kmod-static-nodes.service
642ms systemd-fsck-root.service
626ms systemd-user-sessions.service
611ms sys-kernel-debug.mount
604ms systemd-update-utmp.service
541ms systemd-remount-fs.service
518ms us...@1000.service
478ms systemd-tmpfiles-setup.service
457ms systemd-sysctl.service
448ms rsyslog.service
447ms systemd-modules-load.service
411ms systemd-journal-flush.service
389ms dev-mqueue.mount
387ms systemd-sysusers.service
381ms sys-fs-fuse-connections.mount
361ms systemd-udevd.service
337ms systemd-random-seed.service
273ms sys-kernel-config.mount
234ms systemd-tmpfiles-setup-dev.service
223ms systemd-update-utmp-runlevel.service
151ms ifupdown-pre.service
125ms user-run...@1000.service
94ms bb-wl18xx-bluetooth.service

Looks like i forgot to disable* wl18xx on boot-up on the PocketBeagle..

https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh#L892-L911

debian@beaglebone:~$ sudo systemctl disable bb-wl18xx-bluetooth.service
debian@beaglebone:~$ sudo systemctl disable bb-wl18xx-wlan0.service

debian@beaglebone:~$ systemd-analyze
Startup finished in 7.669s (kernel) + 28.640s (userspace) = 36.310s
graphical.target reached after 28.363s in userspace

debian@beaglebone:~$ sudo rm /boot/initrd.img-4.19.94-ti-r42

debian@beaglebone:~$ systemd-analyze
Startup finished in 1.355s (kernel) + 27.831s (userspace) = 29.187s
graphical.target reached after 27.564s in userspace

debian@beaglebone:~$ systemd-analyze blame
19.893s generic-board-startup.service
19.072s dev-mmcblk0p1.device
3.193s systemd-udev-trigger.service
2.905s loadcpufreq.service
1.898s networking.service
1.427s ssh.service
1.314s systemd-timesyncd.service
1.159s systemd-journald.service
1.043s systemd-logind.service
929ms connman.service
878ms cpufrequtils.service
864ms dnsmasq.service
830ms systemd-fsck-root.service
699ms rsyslog.service
608ms wpa_supplicant.service
578ms systemd-user-sessions.service
557ms sys-kernel-debug.mount
506ms systemd-modules-load.service
506ms us...@1000.service
467ms systemd-tmpfiles-setup.service
465ms systemd-update-utmp.service
452ms kmod-static-nodes.service
399ms systemd-sysusers.service
393ms systemd-journal-flush.service
386ms systemd-sysctl.service
345ms systemd-udevd.service
341ms sys-kernel-config.mount
322ms systemd-random-seed.service
296ms dev-mqueue.mount
284ms sys-fs-fuse-connections.mount
258ms systemd-remount-fs.service
203ms systemd-tmpfiles-setup-dev.service
194ms systemd-update-utmp-runlevel.service
152ms user-run...@1000.service
113ms ifupdown-pre.service


There under 30 seconds, with more room to disable things. ;)

If you kill "generic-board-startup.service" make sure you have a
usb-serial adapter plugged into the usart on the PocketBeagle's uart
pins, as the usb gadget will go away..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Robert Nelson]

Side note, if you disable generic-board-startup.service, just have
something else call:

/bin/sh /opt/scripts/boot/am335x_evm.sh

"after" startup, so your startup will show it booted fast, but then
eventually the usb gadget could be loaded..

[Robert Nelson]

> 2.649s loadcpufreq.service
> 707ms cpufrequtils.service

It's safe to disable cpufrequtils, by default it's already running at
1Ghz out of u-boot and with Performance enabled
with the default kernel..

It's more for legacy..

debian@beaglebone:~$ systemd-analyze
Startup finished in 1.357s (kernel) + 27.030s (userspace) = 28.387s
graphical.target reached after 26.727s in userspace

[Paul Beam]

Robert,

I have been working with the LTS 4.14 ti branch.  Is 4.19 better?  To be honest, I don't remember the image I started with, but I started 6+ months ago.  I'm in a position where I can basically start fresh if there are advantages.  

[Robert Nelson]

On Thu, Apr 23, 2020 at 11:32 AM Paul Beam <rpau...@gmail.com> wrote:
>
> Robert,
>
> I have been working with the LTS 4.14 ti branch. Is 4.19 better? To be honest, I don't remember the image I started with, but I started 6+ months ago. I'm in a position where I can basically start fresh if there are advantages.

Doesn't really matter, for me 4.14.x-ti = stretch, v4.14.x+ is buster,
so if we grab this stretch console image:

https://elinux.org/Beagleboard:Latest-images-testing#Debian_9_.28Stretch.29_Console

Then on the PocketBeagle...

BeagleBoard.org Debian Stretch Console Image 2020-04-06

1st boot...

debian@beaglebone:~$ uname -r
4.14.108-ti-r131

debian@beaglebone:~$ systemd-analyze
Startup finished in 9.701s (kernel) + 44.498s (userspace) = 54.200s

2nd boot...

debian@beaglebone:~$ systemd-analyze
Startup finished in 9.691s (kernel) + 29.165s (userspace) = 38.856s

sudo systemctl disable systembb-wl18xx-bluetooth.service
sudo systemctl disable bb-wl18xx-wlan0.service
sudo systemctl disable wpa_supplicant.service

sudo apt remove cpufrequtils libcpufreq0 hostapd --purge

3rd boot...

debian@beaglebone:~$ systemd-analyze
Startup finished in 9.637s (kernel) + 28.614s (userspace) = 38.252s

sudo rm /boot/initrd.img-4.14.108-ti-r131

4th boot...

debian@beaglebone:~$ systemd-analyze
Startup finished in 1.117s (kernel) + 27.318s (userspace) = 28.436s

[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

[Hans Leeuw]

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 serial...@ttyGS0.service 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 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

[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 serial...@ttyGS0.service

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 us...@1000.service

           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 user-run...@1000.service

            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 us...@1000.service

           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 user-run...@1000.service

            98ms ifupdown-pre.service

            85ms cloud9.service

With serial...@ttyGS0.service 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 us...@1000.service

           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 user-run...@1000.service

           107ms ifupdown-pre.service

            92ms cloud9.service

Op zaterdag 25 april 2020 22:07:01 UTC+2 schreef Paul Beam:

[Paul Beam]

Thanks.  I had to go back to 4.14 since the newest distro broke some things which is taking me a while to figure out.  I did however, eliminate bonescript and I'm ~ 40 seconds which is almost tolerable.