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
HDMI display
Ethernet
PWM
UART
USB
port pins
i2c
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.
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
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 Debian -- Error and probably can't be disabled
unless you install something similar.
systemd-journal handles the systemwide logging functions
systemd-timesyn(cd) handles NTP time synchronization
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).
... 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.
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.
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.
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.
I spent some time this weekend trying to reduce the boot times for my pocketbeagle based things. A few things I discovered:
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.
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.
"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 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
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
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.
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
[ 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.
[ 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
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?
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
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 (generic-board-startup.service takes a long time to run, contributing to slow boot time. · Issue #10 · RobertCNelson/boot-scripts · GitHub)
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:
