Hello Tarmo,
you were right I just disabled the snap package and I earned 22 sec, thanks
for your help.
At the same time, I've realized that I don't need such a modern kernel, so
I decided to test with a more "stable" one.
----- */opt/scripts/tools/version.sh*
git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
eeprom:[A335BNLT000C1908BBBG0612]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Buster IoT TIDL Image 2020-04-06]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
2018.09-00002-g0b54a51eee]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack.dts]
*kernel:[4.14.108-ti-r131]*
nodejs:[v10.15.2]
/boot/uEnv.txt Settings:
pkg check: to individually upgrade run: [sudo apt install --only-upgrade
<pkg>]
pkg:[bb-cape-overlays]:[4.14.20200403.0-0rcnee0~buster+20200403]
pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video
plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc
admin spi iio docker tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4
rootwait coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet]
dmesg | grep remote
[ 1.047276] remoteproc remoteproc0: wkup_m3 is available
[ 1.250805] remoteproc remoteproc0: powering up wkup_m3
[ 1.250830] remoteproc remoteproc0: Booting fw image
am335x-pm-firmware.elf, size 217168
[ 1.251080] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru
dmesg | grep pinctrl-single
[ 0.808485] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size
568
dmesg | grep gpio-of-helper
[ 0.809682] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 002: ID 2357:011e TP-Link
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END
* ------ systemd-analyze*
Startup finished in 6.764s (kernel) + 1min 16.936s (userspace) = 1min
23.700s
graphical.target reached after 1min 15.777s in userspace
*------ NEW* *systemd-analyze blame*
1min 6.796s generic-board-startup.service
44.446s dev-mmcblk0p1.device
4.764s user@0.service
4.016s dnsmasq.service
3.307s loadcpufreq.service
2.724s networking.service
2.387s systemd-udev-trigger.service
1.924s ssh.service
1.786s avahi-daemon.service
1.648s systemd-logind.service
1.405s connman.service
1.401s ti-ipc-dra7xx.service
1.278s systemd-timesyncd.service
1.214s cpufrequtils.service
1.192s systemd-journald.service
1.111s alsa-restore.service
982ms user-runtime-dir@0.service
935ms rsyslog.service
909ms wpa_supplicant.service
902ms systemd-update-utmp-runlevel.service
871ms systemd-fsck-root.service
636ms systemd-user-sessions.service
555ms systemd-modules-load.service
544ms dev-mqueue.mount
503ms sys-kernel-debug.mount
481ms systemd-tmpfiles-setup.service
477ms systemd-udevd.service
457ms kmod-static-nodes.service
456ms systemd-update-utmp.service
440ms cloud9.service
427ms systemd-journal-flush.service
401ms systemd-sysctl.service
401ms systemd-sysusers.service
378ms systemd-random-seed.service
338ms systemd-remount-fs.service
312ms fake-hwclock.service
304ms systemd-tmpfiles-clean.service
290ms ifupdown-pre.service
289ms sys-kernel-config.mount
258ms systemd-tmpfiles-setup-dev.service
218ms sys-fs-fuse-connections.mount
But as you can see the problem is still present, the userspace boot time
takes too much time.
so if it's not the kernel version ... how can I do better times?
El vie., 9 oct. 2020 a las 4:25, Tarmo (<tarmo.ku...@gmail.com>) escribió:
> On Thursday, October 8, 2020 at 11:28:49 PM UTC+3 mfar...@gmail.com wrote:
>
>> kernel:[5.4.47-bone30]
>>
>
> Ooh, kernel 5.4 - how experimental is this?
>
>
>> 1min 34.446s dev-mmcblk0p2.device
>> 1min 2.259s generic-board-startup.service
>> 50.664s dev-loop8.device
>> 49.671s dev-loop7.device
>> 49.351s dev-loop6.device
>> 48.843s dev-loop4.device
>> 48.804s dev-loop5.device
>> 48.462s dev-loop3.device
>> 48.420s dev-loop1.device
>> 48.392s dev-loop0.device
>> 48.197s dev-loop2.device
>>
>
> I haven't seen those dev-loop devices before (perhaps they come with
> kernel 5.4). They look rather suspicious with the 50 second duration. Have
> a look at what their logs say, e.g.:
>
> $ journalctl -u dev-loop0
>
>
>> 24.250s snapd.service
>>
>
> The snap package system is a bit of a resource hog and it primarily serves
> as a convenience for some minority use cases. Are you sure you need it on a
> BBB?
> Final thought - maybe your SD card simply has poor performance? I doubt
> it'll make a significant difference, but you can try flashing your image
> into eMMC or using a higher-end SD card.
>
> --
> Kind regards,
> Tarmo
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/12a87597-62b6-4869-8b01-a97b850854ffn%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/12a87597-62b6-4869-8b01-a97b850854ffn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/CABW7CrdipQ78-rQvYvHV9pXLQyMroJmXC9r2SBJ3YqgK-R_r4A%40mail.gmail.com.
