Reducing Boottime in Beaglebone Black

Hi all,

I am using Beaglebone Black rev C, with debian jessie, for design of One system.

After the BBB is switched ON, it was taking around 1 minute and 35 seconds for the Application screen to appear.
Then I disabled cloud9, gateone and bonescript by using systemctl disable commands. Now boot time is around 1 minute and 10 seconds.
I am using bootchart for seeing the running tasks. I am using it after the bootup(/sbin/bootchartd start and /sbin/bootchartd stop).

There are so many tasks running as shown by bootchart. But I am not in a position decide which one can be removed for getting lesser boot time.

My application requires only the following

  1. HDMI display

  2. Ethernet

  3. PWM

  4. UART

  5. USB

  6. port pins

  7. i2c

  8. spi

Can somebody advice which of the startup tasks may be disabled for getting lesser boot time.

I am seeing tasks like apache2, kworker, haveged, systemd-journal,systemd-timesyn,dnsmasq & systemd-logind. Can these tasks also be disabled by using systemctl disable commands.

What are the other methods to reduce the boot time?

Is it possible to reduce the boot time around 10 seconds?

Expecting the help of Beaglebone Black experts, for solving this issue.

Thanks & Regards,
Sajeevan.K

I've got a FLIR demo currently booting in 15 seconds, from power on to
FLIR data displayed in Xorg..

Much of the speed up comes from v4.14.x+ and mmc access...

Here's the light weight xorg stack details:

https://eewiki.net/display/linuxonarm/FLIR+Lepton+on+BeagleBone+Black+and+Green

One of the big slow-downs in v4.14.x+ is CVE-2018-1108 which massively
slowed down xorg starting due to random number generation changes.

Which i've been playing around with a revert that i haven't pushed out yet..

Regards,

On Thu, 12 Jul 2018 04:33:33 -0700 (PDT),
ksajeevan1975@gmail.com declaimed the
following:

Can somebody advice which of the startup tasks may be disabled for getting
lesser boot time.
I am seeing tasks like apache2, kworker, haveged,
systemd-journal,systemd-timesyn,dnsmasq & systemd-logind. Can these tasks
also be disabled by using *systemctl disable* commands.

  Apache would be the web-server -- unless things have changed, that
handles (among other things) the "bone-101" information pages. Don't know
if cloud9 went through it, or was its own web-server.

  Based upon
https://askubuntu.com/questions/33640/kworker-what-is-it-and-why-is-it-hogging-so-much-cpu?rq=1
you can't disable kworker (though some related threads indicate changing
settings for some interrupt or such to reduce load).

  haveged is a process to initialize the system randomization
https://packages.debian.org/jessie/haveged and probably can't be disabled
unless you install something similar.

  systemd-journal handles the systemwide logging functions
https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs

  systemd-timesyn(cd) handles NTP time synchronization

  systemd-logind handles user login control
https://www.freedesktop.org/software/systemd/man/systemd-logind.service.html

  dnsmasq handles DNS lookups, along with some of the DHCP tasks (likely
the part issuing the 192.168.7.x IPs when connecting via USB).
https://en.wikipedia.org/wiki/Dnsmasq

... So... The only thing you can probably shut down is apache if you never
need to access the device using a web-browser.

Is it possible to reduce the boot time around 10 seconds?

  I haven't seen /any/ Linux that boots that fast -- including those
loading from disk drives on faster hardware (64-bit quad-hyperthreaded core
i7 at 3.4GHz... a single core ARM at 1GHz has no chance <G>). Don't expect
start-up times similar to Arduino, Adafruit Metro, BASIC Stamp, TIVA C (or
MSP432) Launchpads -- even though the board sizes are similar. Those are
microcontrollers and, other than maybe testing the USB port to see if a
firmware download is requested, are basically running the application code
directly -- the application code has all the configuration information for
interrupts and GPIO set-up. (The $12 TIVA 123 is interesting as it actually
has two identical chips on board -- one is the chip "you" are programming,
the other chip handles the debugger and firmware loading operations for the
first chip).

  There have been some variation between Wheezy, Jessie, and Stretch --
in my experience, the one that booted the fastest had the slowest shutdown
(a couple of minutes easily). I no longer have a Wheezy card (and don't
plan to create one for this)

OS (media) Time to Ding dmesg shutdown
Stretch (8GB c-4 SanDisk) 53s 82s 1m34s
Jessie (8GB c-4 SanDisk) 24s 58s 1m35s
Stretch (eMMC) 39s 74s 1m33s
Stretch (eMMC no upgrade) 47s 68s 1m33s

"Time to Ding" is when Windows detected a USB device (measured via
stopwatch from power LED ON, shutdown is from issuing command to LED OFF,
also from stopwatch).

Stretch:
debian@beaglebone:~$ uname -a
Linux beaglebone 4.9.78-ti-r94 #1 SMP PREEMPT Fri Jan 26 21:26:24 UTC 2018
armv7l GNU/Linux
[ 38.327408] configfs-gadget gadget: high-speed config #1: c
[ 39.965089] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
[ 81.918511] ti-pruss 4a300000.pruss: creating PRU cores and other child
platform devices
[ 82.039317] remoteproc remoteproc1: 4a334000.pru0 is available
[ 82.039441] pru-rproc 4a334000.pru0: PRU rproc node
/ocp/pruss_soc_bus@4a326000/pruss@4a300000/pru@4a334000 probed successfully
[ 82.178196] remoteproc remoteproc2: 4a338000.pru1 is available
[ 82.178326] pru-rproc 4a338000.pru1: PRU rproc node
/ocp/pruss_soc_bus@4a326000/pruss@4a30000

Jessie:
debian@beaglebone:~$ uname -a
Linux beaglebone 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l
GNU/Linux
[ 44.812616] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 199,
base_baud = 3000000) is a 8250
[ 44.822677] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 200,
base_baud = 3000000) is a 8250
[ 44.837423] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 201,
base_baud = 3000000) is a 8250
[ 44.859483] eqep 48300180.eqep: ver. 1.0
[ 44.881873] eqep 48302180.eqep: ver. 1.0
[ 44.915463] eqep 48304180.eqep: ver. 1.0
[ 44.943934] omap_i2c 4802a000.i2c: bus 1 rev0.11 at 100 kHz
[ 44.961414] bone_capemgr bone_capemgr: slot #4: dtbo
'cape-universaln-00A0.dtbo' loaded; overlay id #0
[ 45.826277] asoc-simple-card sound: i2s-hifi <-> 48038000.mcasp mapping
ok
[ 58.072852] CAN device driver interface
[ 58.258323] c_can_platform 481cc000.can: c_can_platform device
registered (regs=fa1cc000, irq=210)
[ 58.313802] c_can_platform 481d0000.can: c_can_platform device
registered (regs=fa1d0000, irq=211)

  Hmmm, looks like Jessie is still using a kernel-time device tree
overlay...

  For comparison, an R-Pi 3B (1.2GHz quad-core) appears to take 37s to
boot (fewer peripherals to set up, I suspect):

pi@raspberrypi:~$ uname -a
Linux raspberrypi 4.14.34-v7+ #1110 SMP Mon Apr 16 15:18:51 BST 2018 armv7l
GNU/Linux
[ 22.640526] Bluetooth: RFCOMM ver 1.11
[ 22.871633] Under-voltage detected! (0x00050005)
[ 22.878826] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote
wakeup
[ 23.323464] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 24.386654] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa
0xCDE1
[ 29.111584] Voltage normalised (0x00000000)
[ 34.339739] fuse init (API version 7.26)
[ 37.309900] EXT4-fs (mmcblk0p5): mounted filesystem with ordered data
mode. Opts: (null)

Can't really do shutdown timing as the power LED never goes off on an R-Pi.

Hi Robert Nelson,

Thank You very much for Your exact reply.

Now I am using lxqt image(bone-debian-8.7-lxqt-4gb-armhf-2017-03-19-4gb.img) and this image is loaded in an SD card. And BBB is booting from SD card.

As per Your reply, what I understood is, for getting a boot time of around 15seconds, I should use an iot image(which does not have graphical desktop), and BBB should boot from emmc.

At this point, I have the following doubts.

By just using iot image(instead of lxqt image) and booting from emmc(instead of SD card boot), is it possible to reduce the boot time around 15 seconds ?

Even without graphical desktop like lxqt, can I run qt gui applications in Beaglebone black with startx command and x window manager?

Is ssh through USB is supported with iot image?

Earlier I also was using emmc. I shifted to SD card, because 4GB was insufficient for installing some packages and all.

But now I just require to install qt-sdk, and even with that the flash usage is only around 3.5G.

Please clarify these points, so that I can have a try, for getting a lesser boot time, with emmc boot and iot image.

Thanks & Regards,
Sajeevan.K

Hi Dennis Lee,

Thank You very much for Your detailed reply with useful explanations and links.
From Your reply, I could understand that, we cannot reduce the boot time much by disabling startup programs. Most of this services are required for normal functionality.

Let me have a try by using iot image and emmc boot and check how much boot time, shall be reduced with it.

Thanks & Regards,
Sajeevan.K

Hi Robert Nelson,

Thank You very much for Your exact reply.

Now I am using lxqt image(bone-debian-8.7-lxqt-4gb-armhf-2017-03-19-4gb.img)
and this image is loaded in an SD card. And BBB is booting from SD card.

As per Your reply, what I understood is, for getting a boot time of around
15seconds, I should use an iot image(which does not have graphical desktop),
and BBB should boot from emmc.

No, the "IOT" image isn't required.. You could use the lxqt image,
but it's eaiser to start minimal and build up, then removed a few
hundred applications in the lxqt image..

At this point, I have the following doubts.

By just using iot image(instead of lxqt image) and booting from emmc(instead
of SD card boot), is it possible to reduce the boot time around 15 seconds ?

Actually the 8-bit eMMC is slower then some of my 4-bit microSD card's...

15 seconds on microSD would not be a problem..

Even without graphical desktop like lxqt, can I run qt gui applications in
Beaglebone black with startx command and x window manager?

In my case i'm using openbox/xorg.

Is ssh through USB is supported with iot image?

all images..

Earlier I also was using emmc. I shifted to SD card, because 4GB was
insufficient for installing some packages and all.

But now I just require to install qt-sdk, and even with that the flash usage
is only around 3.5G.

So "build" your application on one beagle with teh sdk, and then
transfer it to the other beagle with the minimal xorg setup...

Please clarify these points, so that I can have a try, for getting a lesser
boot time, with emmc boot and iot image.

Regards,

The big thing you need to remember, the "example" images are just
that. Example with everything enabled, so any user can just jump in..

Start with the small iot image and build up, then it's pretty easy to
minimize boot times..

Here's another one i'm working on:

root@arm:~# systemd-analyze
Startup finished in 1.543s (kernel) + 7.661s (userspace) = 9.204s
root@arm:~# uname -r
4.14.54-ti-r63

We are still getting killed by the fix for CVE-2018-1108 in v4.14.x

root@arm:~# dmesg | grep random:
[ 0.000000] random: get_random_bytes called from
start_kernel+0xac/0x460 with crng_init=0
[ 0.992879] random: fast init done
[ 1.676263] random: systemd: uninitialized urandom read (16 bytes read)
[ 1.679747] random: systemd: uninitialized urandom read (16 bytes read)
[ 1.875247] random: systemd-sysv-ge: uninitialized urandom read (16
bytes read)
[ 119.839484] random: crng init done
[ 119.839507] random: 7 urandom warning(s) missed due to ratelimiting

2 minute delay for "random: crng init done" so many userspace
applications get stuck waiting for that...

Regards,

On Fri, 13 Jul 2018 06:15:41 -0700 (PDT),
ksajeevan1975@gmail.com declaimed the
following:

Let me have a try by using iot image and emmc boot and check how much boot
time, shall be reduced with it.

  Though you may have to start with an older IoT image, given R. Nelson's
comments about some "fix" killing boot times

https://access.redhat.com/security/cve/cve-2018-1108

(Hmmm, wonder if that affects the haveged process too)

I spent some time this weekend trying to reduce the boot times for my pocketbeagle based things. A few things I discovered:

  1. The existence of an initrd in /boot adds 19 seconds to the boot. This is seen in the dmesg logs where the “EXT4-fs (mmcblk0p1): mounted filesystem” line is at the 20 second mark instead of the 1.1 second mark. No idea why, but since the initrd isn’t needed with the ext4 roots, just deleting it is huge. Too bad update_kernel creates it.

  2. generic-board-startup.service takes up a HUGE amount of time, over 40 seconds. I started debugging into it and 30 seconds of that is just calling “systemctl start serial-getty@ttyGS0.service || true”. Changing that to “systemctl start serial-getty@ttyGS0.service &” drops boot time by almost 30 seconds. Is that something we could just “systemctl enable” and let systemd start it if ttyGS0 is found and not have to deal with it in the generic-board-startup? It’s a lot of time saved.

“config-pin -f pins.txt” also takes several seconds when configuring all 55 GPIO pins. I might look at optimizing that a bit for my use case by not using config-pin and just use the /sys/class/gpio stuff directly in my own script. Only a couple seconds though.

I spent some time this weekend trying to reduce the boot times for my
pocketbeagle based things. A few things I discovered:

1) The existence of an initrd in /boot adds 19 seconds to the boot. This
is seen in the dmesg logs where the "EXT4-fs (mmcblk0p1): mounted
filesystem" line is at the 20 second mark instead of the 1.1 second mark.
No idea why, but since the initrd isn't needed with the ext4 roots, just
deleting it is huge. Too bad update_kernel creates it.

This is only needed for kernels: 3.8 -> 4.3.x-ish (uuid mmc id) and
3.8 -> 4.1.x (kernel overlays)..

I'm thinking of nuking the initrd by default going forward..

2) generic-board-startup.service takes up a HUGE amount of time, over 40
seconds. I started debugging into it and 30 seconds of that is just calling
"systemctl start serial-getty@ttyGS0.service || true". Changing that to
"systemctl start serial-getty@ttyGS0.service &" drops boot time by almost 30
seconds. Is that something we could just "systemctl enable" and let systemd
start it if ttyGS0 is found and not have to deal with it in the
generic-board-startup? It's a lot of time saved.

Good point, no reason to not fork that. :wink:

"config-pin -f pins.txt" also takes several seconds when configuring all 55
GPIO pins. I might look at optimizing that a bit for my use case by not
using config-pin and just use the /sys/class/gpio stuff directly in my own
script. Only a couple seconds though.

Regards,

Hi Robert Nelson, Dennis Lee & Daniel Kulp,

Thank You very much for the reply and support.

I have been little busy with some other tasks. So I couldn’t test with the iot image.
I am hopeful in the idea of starting from iot image and build up from it.

Will the fix for CVE-2018-1108, affect the normal booting of Beaglebone black? Is there a chance that normal applications access random data at boot time?

Is this fix applied only for Kernel 4.14. Can we avoid this problem by using kernel 4.4 or 4.9(I think Our application does not require that much big security). What about building a minimal image for beaglebone black with kernel 4.4 or 4.9 as shown in

https://eewiki.net/display/linuxonarm/BeagleBone+Black.

Thanks & Regards,
Sajeevan.K

Even with the fix for that CVE, v4.14.x is still faster then v4.9.x..
It just use to be 'way' faster..

Regards,

Hi Robert Nelson,

I shall start with v4.14 iot image and build up from it. Thank You very much.

Thanks & Regards,
Sajeevan.K

Hi everybody, it seems 2 years passed from the last message, I hope Robert Nelson can see that message and help me too.
I have the similar problem, but mine is a bit different.
Similar to FLIR, I want to run just one qt app. But I also need TCA8418 keypad driver, which is not compiled et any of the brebuiled image kernel. Therefore, i tried to build my own kernel with that driver selected at the configurator. It worked good, but boot time is so much. (2:40). Acording to this topic, i understand that reducing this time is a bit difficult if i use mine image. If i strt to use IoT image sources, while building my image then it would be better. But i can not find any information that tells how an IoT iamge is produced.
By the way, i am not sure the selected way is the correct one. May be adding the driver to the prebuild image would be a better choice. But i do not know how to do.

Thanks in advance,

18 Temmuz 2018 Çarşamba tarihinde saat 17:57:58 UTC+3 itibarıyla sajeevan k şunları yazdı:

Hi Robert,
Awesome work with the Beaglebone OS and tools. Entry point for a beginier is so much simplified using the tools you provide.
I know this topic is OLD.
I have been trying to get my boot times with a BBB down from about 50s to 20s
I have started with a Debian Stretch 9.12 console image. Upgraded it to realtime kernel 4.19. Booting from EMMC.
Trying to get a single console app or X11 app open in less than 20-25s
This is my output for systemd-analyze blame

debian@beaglebone:~$ systemd-analyze
Startup finished in 1.690s (kernel) + 50.841s (userspace) = 52.532s
debian@beaglebone:~$ systemd-analyze blame
1min 15.560s dev-mmcblk1p1.device
8.459s generic-board-startup.service
4.654s systemd-udev-trigger.service
3.188s loadcpufreq.service
2.620s networking.service
2.157s keyboard-setup.service
1.791s systemd-logind.service
1.711s dnsmasq.service
1.631s ssh.service
1.529s rsyslog.service
1.429s user@1001.service
1.418s systemd-journald.service
1.204s cpufrequtils.service
1.071s systemd-timesyncd.service
918ms systemd-fsck-root.service
597ms systemd-udevd.service
528ms dev-mqueue.mount
515ms sys-kernel-debug.mount
495ms systemd-tmpfiles-setup-dev.service
469ms systemd-tmpfiles-setup.service
451ms systemd-sysctl.service
417ms systemd-modules-load.service
400ms systemd-user-sessions.service
388ms sys-fs-fuse-connections.mount
369ms systemd-journal-flush.service
355ms slim.service
324ms systemd-update-utmp.service
311ms sys-kernel-config.mount
303ms kmod-static-nodes.service
300ms systemd-remount-fs.service
238ms console-setup.service
210ms systemd-random-seed.service
140ms systemd-update-utmp-runlevel.service
debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-rt-r63 #1stretch SMP PREEMPT RT Fri May 14 16:42:35 UTC 2021 armv7l GNU/Linux

Any advise you can give to reduce the userspace time further?
IT would be really helpful if you could list the optimizations you did for the FLIR demo app.

Regards,
amit

Hi Amit,

Interesting. 4.19.94 is a only a little bit faster than 4.14.108. Is there a document somewhere that explains what to do to even just speed up both start up and shut down?

What did you do to get it to 50 seconds?

John

debian@ebb:~$ uname -a

Linux ebb 4.14.108-ti-r136 #1stretch SMP PREEMPT Mon Jun 8 15:38:30 UTC 2020 armv7l GNU/Linux

debian@ebb:~$ systemd-analyze

Startup finished in 40.059s (kernel) + 1min 27.889s (userspace) = 2min 7.948s

debian@ebb:~$ systemd-analyze blame

1min 47.177s dev-mmcblk0p1.device

1min 13.819s generic-board-startup.service

debian@beaglebone:~$ uname -a

Linux beaglebone 4.19.94-ti-r63 #1buster SMP PREEMPT Fri May 14 16:42:32 UTC 2021 armv7l GNU/Linux

debian@beaglebone:~$ systemd-analyze

Startup finished in 26.608s (kernel) + 1min 32.506s (userspace) = 1min 59.114s

graphical.target reached after 1min 32.205s in userspace

debian@beaglebone:~$ systemd-analyze blame

1min 20.997s generic-board-startup.service

1min 4.519s dev-mmcblk0p1.device

11.344s udisks2.service

Just to add a data point: Buster IoT image on uSD card...

debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55
UTC 2020 armv7l GNU/Linux

debian@beaglebone:~$ systemd-analyze
Startup finished in 10.915s (kernel) + 1min 961ms (userspace) = 1min
11.877s
graphical.target reached after 1min 668ms in userspace

  That's odd -- Did I leave the LXQT image in the board (I have uSD for
both IoT and LXQT)

debian@beaglebone:~$ systemd-analyze blame
         51.745s generic-board-startup.service
         40.798s dev-mmcblk0p1.device
          4.064s nginx.service
          3.587s systemd-udev-trigger.service

  From DMESG one finds such ...

[ 1.668861] ALSA device list:
[ 1.668877] #0: TI BeagleBone Black
[ 1.675450] Freeing unused kernel memory: 1024K
[ 1.676178] Run /init as init process
[ 2.664089] [drm] Cannot find any crtc or sizes
[ 10.155042] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data
mode. Opts: (null)
[ 10.955497] systemd[1]: System time before build time, advancing clock.

  EIGHT seconds mounting file system

[ 13.203659] EXT4-fs (mmcblk0p1): re-mounted. Opts: errors=remount-ro
[ 14.816264] systemd-journald[893]: Received request to flush runtime
journal from PID 1
[ 21.928916] net eth0: initializing cpsw version 1.12 (0)
[ 22.000769] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver
[SMSC LAN8710/LAN8720] (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)

  SEVEN seconds initializing eth0

[ 27.071692] configfs-gadget gadget: high-speed config #1: c
[ 27.072147] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
[ 27.277845] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
[ 69.566416] remoteproc remoteproc0: wkup_m3 is available
[ 69.658941] remoteproc remoteproc0: powering up wkup_m3
[ 69.658973] remoteproc remoteproc0: Booting fw image
am335x-pm-firmware.elf, size 217168

  FORTY seconds preparing the PRUs with remoteproc

  Let me switch uSD card...

debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55
UTC 2020 armv7l GNU/Linux

debian@beaglebone:~$ systemd-analyze
Bootup is not yet finished
(org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs
debian@beaglebone:~$ systemctl list-jobs
JOB UNIT TYPE STATE
89 getty.target start waiting
69 generic-board-startup.service start running
97 serial-getty@ttyGS0.service start waiting
  2 multi-user.target start waiting
  1 graphical.target start waiting
81 systemd-update-utmp-runlevel.service start waiting
98 dev-ttyGS0.device start running

7 jobs listed.

  Hmmm, looks like I need to attach an HDMI cable and monitor to
determine which has the LXQT image...

debian@beaglebone:~$ systemctl list-jobs
No jobs running.

debian@beaglebone:~$ systemd-analyze
Startup finished in 11.355s (kernel) + 1min 24.913s (userspace) = 1min
36.268s
graphical.target reached after 1min 24.632s in userspace
debian@beaglebone:~$ systemd-analyze blame
    1min 15.551s generic-board-startup.service
     1min 1.691s dev-mmcblk0p1.device
          9.380s udisks2.service

  DMESG output snippets

[ 1.928371] Run /init as init process
[ 2.920215] [drm] Cannot find any crtc or sizes
[ 10.473694] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data
mode. Opts: (null)
[ 11.394359] systemd[1]: System time before build time, advancing clock.

  SEVEN and a half seconds mounting filesystem

[ 14.116062] EXT4-fs (mmcblk0p1): re-mounted. Opts: errors=remount-ro
[ 15.517709] systemd-journald[901]: Received request to flush runtime
journal from PID 1
[ 22.417276] net eth0: initializing cpsw version 1.12 (0)
[ 22.532858] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver
[SMSC LAN8710/LAN8720]

  SEVEN on eth0

[ 29.411733] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
[ 29.769247] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
[ 93.327879] remoteproc remoteproc0: wkup_m3 is available
[ 93.335402] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle
[ 93.484677] remoteproc remoteproc0: powering up wkup_m3

  SIXTY on PRU remoteproc stuff.

Hi Amit,

Interesting. 4.19.94 is a only a little bit faster than 4.14.108. Is there a document somewhere that explains what to do to even just speed up both start up and shut down?

What did you do to get it to 50 seconds?

John

Hi John,

I did not do much actually to get to 50s.
Started from a console Image : https://rcn-ee.com/rootfs/bb.org/testing/2020-05-02/stretch-console/bone-eMMC-flasher-debian-9.12-console-armhf-2020-05-02-1gb.img.xz
replaced the kernel:

cd /opt/scripts/tools/

sudo su

git pull

./update_kernel.sh --ti-rt-channel --lts-4_19

removed wpasupplicant and connman and old kernel

sudo apt-get purge linux-image-4.14.108-ti-r134 wpasupplicant connman

debian@beaglebone:~$ systemd-analyze

Startup finished in 13.502s (kernel) + 36.686s (userspace) = 50.188s

I then removed the initrd file in /boot directory (From what I understand this kernel does not necessarily need initrd).
debian@beaglebone:/boot$ sudo mv initrd.img-4.19.94-ti-rt-r63 moved-initrd.img-4.19.94-ti-rt-r63

Removing the initrd gives the max speedup for kernel. From 10s-13s with initrd, it reduces to 1s-2s

debian@beaglebone:~$ systemd-analyze
Startup finished in 1.663s (kernel) + 36.385s (userspace) = 38.048s
debian@beaglebone:~$ systemd-analyze blame
1min 4.266s dev-mmcblk1p1.device
26.360s generic-board-startup.service
3.847s systemd-udev-trigger.service
2.824s loadcpufreq.service
2.215s networking.service
1.647s ssh.service
1.396s user@1000.service
1.209s rsyslog.service
1.189s systemd-journald.service
999ms dnsmasq.service
897ms cpufrequtils.service
855ms systemd-timesyncd.service
674ms systemd-fsck-root.service
642ms systemd-logind.service
505ms systemd-udevd.service
445ms systemd-user-sessions.service
408ms systemd-tmpfiles-setup-dev.service
389ms systemd-update-utmp.service
375ms hostapd.service
365ms systemd-modules-load.service
326ms dev-mqueue.mount
324ms systemd-random-seed.service
312ms sys-kernel-config.mount
291ms systemd-tmpfiles-setup.service
274ms sys-kernel-debug.mount
236ms kmod-static-nodes.service
231ms sys-fs-fuse-connections.mount
200ms systemd-remount-fs.service
190ms systemd-journal-flush.service
185ms systemd-sysctl.service
145ms systemd-update-utmp-runlevel.service
130ms systemd-tmpfiles-clean.service

Next point to attack is the generic-board-startup.service. The main time that process spends is in the file /opt/scripts/boot/am335x_evm.sh
This takes care of the USB flash, Serial and network gadgets that are initialized. Remove items which are not needed. It also has a lot of generic selections for Beagle family boards which can be removed. I am working on my version for just beaglebone black with only network over USB support.
Some ideas can be found here (https://github.com/RobertCNelson/boot-scripts/issues/10)

Hope that helps.

-amit

Thanks. Yes. It does.

John

removed wpasupplicant and connman and old kernel

sudo apt-get purge linux-image-4.14.108-ti-r134 wpasupplicant connman

debian@beaglebone:~$ systemd-analyze

Startup finished in 13.502s (kernel) + 36.686s (userspace) = 50.188s

I then removed the initrd file in /boot directory (From what I understand this kernel does not necessarily need initrd).
debian@beaglebone:/boot$ sudo mv initrd.img-4.19.94-ti-rt-r63 moved-initrd.img-4.19.94-ti-rt-r63

Removing the initrd gives the max speedup for kernel. From 10s-13s with initrd, it reduces to 1s-2s
debian@beaglebone:~$ systemd-analyze
Startup finished in 1.663s (kernel) + 36.385s (userspace) = 38.048s
debian@beaglebone:~$ systemd-analyze blame
     1min 4.266s dev-mmcblk1p1.device
         26.360s generic-board-startup.service
          3.847s systemd-udev-trigger.service
          2.824s loadcpufreq.service

You can nuke this ^, it's really only for am57xx, so we can
downclock.. But on am335x, let it run at full speed as these are set:

CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y

          2.215s networking.service
          1.647s ssh.service
          1.396s user@1000.service
          1.209s rsyslog.service
          1.189s systemd-journald.service
           999ms dnsmasq.service
           897ms cpufrequtils.service

Same as above..

           855ms systemd-timesyncd.service
           674ms systemd-fsck-root.service
           642ms systemd-logind.service
           505ms systemd-udevd.service
           445ms systemd-user-sessions.service
           408ms systemd-tmpfiles-setup-dev.service
           389ms systemd-update-utmp.service
           375ms hostapd.service

You nuked wpasupplicant, get rid of hostapd..