BBBW Boot optimization

GoogleGroups
1

Hello,
I know boot optimization has been already discussed but none of the discussions I read completely solved the problem.

I’m working on this device which needs:

  • 4 UARTs
  • a number of GPIO as output and some as input
  • one PRU
  • wireless (internet over WiFi and BT)

Everything is manged by a Python script which is started automatically by a systemd service (nfc-multireader.service).

I’m trying to reduce the boot time since, at some point of the work, from power-on to the device to be usable (application running) it was more than 90s.

For now I performed these steps in order to reduce it:

  • updated bootloader and kernel (see version.sh below)
  • removed the file /boot/initrd.img-4.14.xxxxx (I read this somewhere, I don’t remember where…it reduces the kernel loading time)
  • turned off the wifi AP. This makes the bb-wl18xx-wlan0.service to start much faster
  • masked ttyGS0 device (serial port through the microUSB)
    (I decided to do the last two point because using systemd-analyze I saw dev-ttyGS0.device and bb-wl18xx-wlan0.service to be blocked in wating state for 60s during boot)

Now systemd-analyze shows pretty good performance (see image)
boot.png
my application (nfc-multireader.service) is started at t=15s, which is acceptable and I don’t pretend to have it faster, however some of the resources it relies on (in particular internet connectivity and the PRU) become available a while later.
In particular, PRU takes further 25s to be ready (before this time, the /dev/uio device is not there), while internet other 10s.
Then, even if the application is launched at t=15s, it becomes usable only at t=50s.

I also noticed that if I remove the enable_uboot_cape_universal=1 option in the /boot/uEnv.txt everything is faster (the system is up and running in 30s approximately), however this makes GPIOs unavailable (all the other functionalities are still there).

Then I ask three questions:

  • given my boot (see image above) is it normal that dev-mmcblk1p1.device is in ‘activating’ state for such a long time? Can I make it faster?

  • can anybody guess why is it taking so long to create /dev/uio and to connect to internet?

  • as workaround I could remove enable_uboot_cape_universal=1, but then is there any way to enable GPIOs once booted without the universal cape?

Thank you very much, here my version.sh:

git:/opt/scripts/:[73593ebe3b7d3cc381eeb502d45ccb33a6ec5e78]
eeprom:[A335BNLTBWA51905BBWG0440]
model:[TI_AM335x_BeagleBone_Black_Wireless]
dogtag:[BeagleBoard.org Debian Image 2018-08-30]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-gc8b5ad3a1f]:[location: dd MBR]
kernel:[4.14.108-ti-r104]
nodejs:[v6.14.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[disable_uboot_overlay_adc=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/BB-UART1-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr1=/lib/firmware/BB-UART2-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr2=/lib/firmware/BB-UART4-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr3=/lib/firmware/BB-UART5-00A0.dtbo]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade ]
pkg:[bb-cape-overlays]:[4.4.20190429.0-0rcnee0~stretch+20190429]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.2-git20180829.0-0rcnee0~stretch+20180830]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet]
dmesg | grep pinctrl-single
[ 0.690027] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
dmesg | grep gpio-of-helper
[ 0.702147] gpio-of-helper ocp:cape-universal: ready
END

2

Your missing a few optimizations that have pushed all over the place in the image since 2018-08-30, for a quick comparison grab this image…

https://rcn-ee.net/rootfs/bb.org/testing/2019-04-28/stretch-iot/bone-debian-9.9-iot-armhf-2019-04-28-4gb.img.xz

Note, on first bootup, it will take longer, as we now pre-install the correct sgx drivers, after ssh generation…

But then compare the 2nd bootup, with your current install…

Regards,

boot.png

3

Thank you Robert for your fast response.

I just tried the image you posted.

The boot looks a bit better, dev-ttyGS0.device is no more critical and the bb-wl18xx-wlan0.service is faster (see image below), but generic-board-startup.service now takes longer.

Anyway, internet over the wifi doesn’t become operative before 60s (which is approximately the same as before).
For the application internet is mandatory, then the sooner it is enabled the better it is. Can I do anything else to shorten the time to be online?
One thing I forgot to mention is that I’m connecting to an eduroam wifi network, which requires PEAP authentication.

new_linux_boot_NOinitrd_nfcservice.png

Davide.

4

Hi Davide!

5

Robert,

Is there any place to go to compare the differences between images over time? I’m running a console 9.5 image which I’ve heavily customized. If possible I’d rather upgrade incrementally instead of starting from scratch customizing a new image.

Or is that too painful a way to update? I’m also interested in improving boot time.

Thanks,

Jim

boot.png