Bug #1233
open
Boot to MIOT logo is very long
20%
Description
It takes too long to get to the splash screen.
I need to run some bootchart tests again. See RM #472.
See:- Instant Pi discusses methods to boot fast, but there isn't anything to do to speed up the bootloader except maybe boot via a faster SD card.
- Overclocking Pis
- Busybox Bootchard from elinux.org; this is the way to configure the boot.
bootchard is enabled in the Busybox config so this should be straightforward to run a test.
I will need pybootchartgui from bootchart2 to generate the PNG graph. The default bootchartd installed on Debian may have the same tool but it might not work with Busybox's bootchartd.
Files
Updated by Hammel 27 days ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
Based on the eLinux.org description, it would seem all I need to do is add the following to the cmdline.txt file to run bootchartd.
rdinit=/sbin/bootchartd
Updated by Hammel 27 days ago
- File bootchart.png bootchart.png added
- % Done changed from 10 to 20
Almost. Use this instead:
init=/sbin/bootchartd bootchart_init=/sbin/initThe results are stored in /var/log/bootlog.tgz. Copy this to a host system and clone this updated bootchart. Edit the pybootchartgui.py and change the shebang to #!/usr/bin/python3 and make sure python-cairo is installed. Then run
<path-to-pybootchargui.py>/pybootchartgui.py bootlog.tgzThe output will be called bootchart.png and will be stored in the same directory where bootlog.tgz is (which should be the directory your in).
Here is my first attempt at this, on a kiosk system.
Updated by Hammel 27 days ago
Looks like we're back to network startup being the major holdup. That takes nearly 25 seconds. If I put that in the background I can certainly get to a UI faster. What needs to go into the background:
- S40network
- S60nfs
- S80dhcp-relay
- S91smb
I may also need to put the following in the background.
- ntp
- lighttpd
- dropbear
Updated by Hammel 27 days ago
None of these init scripts is part of of the PiBox skeleton except S40network. So the only way to modify them would be to remove them in the postbuild.sh script and have a skeleton alternative, a new S40network, that handles running them all in the background.
This implies bringing up the network interfaces first, and when those are up run the other scripts.
It might be useful to find out what happens if S40network, as it is now, is run in the background but leave everything else alone. If the other daemons still work even though they start BEFORE networking does then all we really need is to background networking.
Updated by Hammel 27 days ago
Ran a simple test where I put the start) code into the background using a double fork in S40network. That didn't work. While I know the backgrounding mechanism (re: double fork) would normally work, it doesn't work with that script in that way. It will require deeper analysis.
I wondered if I could code this in C instead so I looked up the code to Busybox's ifup and found it's just a C wrapper around various commands like ip and dhcpd. What make take a long time is the various setup I do within S40network, not in ifup, although the dhcpd call is definitely a bottleneck.
To make this run as a background process I could write a small C program that does what the shell script does and then launch it as a background process. That should allow me to move all networking to a background startup. This could be written as a small app that replaces S40network (and related init scripts) and handles them external to the normal init processing.
If I do this I will need to check that the launcher status bar can pick up when networking is running and update the date/time field and the network icon. The latter probably already works but the former may need to operate like the icon does.