BBBW Boot optimization

136 views
Skip to first unread message

dgiov...@fbk.eu

unread,
May 7, 2019, 12:20:31 PM5/7/19
to BeagleBoard
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>]
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


--
Le informazioni contenute nella presente comunicazione sono di natura privata e come tali sono da considerarsi riservate ed indirizzate esclusivamente ai destinatari indicati e per le finalità strettamente legate al relativo contenuto. Se avete ricevuto questo messaggio per errore, vi preghiamo di eliminarlo e di inviare una comunicazione all’indirizzo e-mail del mittente.
--
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material.

Robert Nelson

unread,
May 7, 2019, 12:30:15 PM5/7/19
to Beagle Board, dgiov...@fbk.eu
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..


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,

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

dgiov...@fbk.eu

unread,
May 8, 2019, 7:47:13 AM5/8/19
to BeagleBoard
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.

TJF

unread,
May 8, 2019, 10:29:02 AM5/8/19
to BeagleBoard
Hi Davide!


Am Dienstag, 7. Mai 2019 18:20:31 UTC+2 schrieb dgiov...@fbk.eu:
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).

This issue can get solved by libpruio. You wont need a custom device tree blob. And it also replaces libprussdrv, saving a little more time.

Regards

Jim F

unread,
May 8, 2019, 12:28:06 PM5/8/19
to beagl...@googlegroups.com
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

--
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/CAOCHtYgjWKzZo3R08pw7o2HLfJJrkQzMSq%3DQGpTZ6bq4H02xFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages