Reducing Boottime in Beaglebone Black

3045 views
Skip to first unread message

ksajee...@gmail.com

unread,
Jul 12, 2018, 8:10:43 AM7/12/18
to BeagleBoard
Hi all,

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
1) HDMI display
2) Ethernet
3) PWM
4) UART
5) USB
6) port pins
7) i2c
3) 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.


Thanks & Regards,
Sajeevan.K

Robert Nelson

unread,
Jul 12, 2018, 10:28:57 AM7/12/18
to Beagle Board, ksajee...@gmail.com
I've got a FLIR demo currently booting in 15 seconds, from power on to
FLIR data displayed in Xorg..

Much of the speed up comes from v4.14.x+ and mmc access...

Here's the light weight xorg stack details:

https://eewiki.net/display/linuxonarm/FLIR+Lepton+on+BeagleBone+Black+and+Green

One of the big slow-downs in v4.14.x+ is CVE-2018-1108 which massively
slowed down xorg starting due to random number generation changes.

Which i've been playing around with a revert that i haven't pushed out yet..

Regards,

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

Dennis Lee Bieber

unread,
Jul 12, 2018, 12:33:17 PM7/12/18
to beagl...@googlegroups.com
On Thu, 12 Jul 2018 04:33:33 -0700 (PDT),
ksajee...@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
https://askubuntu.com/questions/33640/kworker-what-is-it-and-why-is-it-hogging-so-much-cpu?rq=1
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
https://packages.debian.org/jessie/haveged and probably can't be disabled
unless you install something similar.

systemd-journal handles the systemwide logging functions
https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs

systemd-timesyn(cd) handles NTP time synchronization

systemd-logind handles user login control
https://www.freedesktop.org/software/systemd/man/systemd-logind.service.html

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).
https://en.wikipedia.org/wiki/Dnsmasq

... 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.


--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

ksajee...@gmail.com

unread,
Jul 13, 2018, 11:55:21 AM7/13/18
to BeagleBoard
Hi Dennis Lee,


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.



Thanks & Regards,
Sajeevan.K

ksajee...@gmail.com

unread,
Jul 13, 2018, 11:55:25 AM7/13/18
to BeagleBoard
Hi Robert Nelson,

Thank You very much for Your exact reply.

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.


Thanks & Regards,
Sajeevan.K

Robert Nelson

unread,
Jul 13, 2018, 12:04:35 PM7/13/18
to Beagle Board
On Fri, Jul 13, 2018 at 8:07 AM, <ksajee...@gmail.com> wrote:
> Hi Robert Nelson,
>
> Thank You very much for Your exact reply.
>
> 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.

Robert Nelson

unread,
Jul 13, 2018, 12:10:56 PM7/13/18
to Beagle Board
The big thing you need to remember, the "example" images are just
that. Example with everything enabled, so any user can just jump in..

Start with the small iot image and build up, then it's pretty easy to
minimize boot times..

Here's another one i'm working on:

root@arm:~# systemd-analyze
Startup finished in 1.543s (kernel) + 7.661s (userspace) = 9.204s
root@arm:~# uname -r
4.14.54-ti-r63

We are still getting killed by the fix for CVE-2018-1108 in v4.14.x

root@arm:~# dmesg | grep random:
[ 0.000000] random: get_random_bytes called from
start_kernel+0xac/0x460 with crng_init=0
[ 0.992879] random: fast init done
[ 1.676263] random: systemd: uninitialized urandom read (16 bytes read)
[ 1.679747] random: systemd: uninitialized urandom read (16 bytes read)
[ 1.875247] random: systemd-sysv-ge: uninitialized urandom read (16
bytes read)
[ 119.839484] random: crng init done
[ 119.839507] random: 7 urandom warning(s) missed due to ratelimiting

2 minute delay for "random: crng init done" so many userspace
applications get stuck waiting for that...

Dennis Lee Bieber

unread,
Jul 13, 2018, 1:16:15 PM7/13/18
to beagl...@googlegroups.com
On Fri, 13 Jul 2018 06:15:41 -0700 (PDT),
ksajee...@gmail.com declaimed the
following:


>Let me have a try by using iot image and emmc boot and check how much boot
>time, shall be reduced with it.
>
Though you may have to start with an older IoT image, given R. Nelson's
comments about some "fix" killing boot times

https://access.redhat.com/security/cve/cve-2018-1108

(Hmmm, wonder if that affects the haveged process too)

Daniel Kulp

unread,
Jul 16, 2018, 9:43:16 AM7/16/18
to BeagleBoard

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.

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...@ttyGS0.service || true".   Changing that to "systemctl start serial...@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.

Robert Nelson

unread,
Jul 16, 2018, 10:50:40 AM7/16/18
to Beagle Board
On Mon, Jul 16, 2018 at 8:43 AM, Daniel Kulp <d...@kulp.com> wrote:
>
> 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...@ttyGS0.service || true". Changing that to
> "systemctl start serial...@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.

sajeevan k

unread,
Jul 16, 2018, 11:01:17 AM7/16/18
to BeagleBoard

Hi Robert Nelson, Dennis Lee & Daniel Kulp,


Thank You very much for the reply and support.

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  




Thanks & Regards,
Sajeevan.K

Robert Nelson

unread,
Jul 16, 2018, 11:05:57 AM7/16/18
to Beagle Board
On Mon, Jul 16, 2018 at 10:01 AM, sajeevan k <saje...@laxven.com> wrote:
>
> Hi Robert Nelson, Dennis Lee & Daniel Kulp,
>
>
> Thank You very much for the reply and support.
>
> 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?

Even with the fix for that CVE, v4.14.x is still faster then v4.9.x..
It just use to be 'way' faster..

sajeevan k

unread,
Jul 18, 2018, 10:57:58 AM7/18/18
to BeagleBoard
Hi Robert Nelson,

I shall start with v4.14 iot image and build up from it. Thank You very much. 

Thanks & Regards,
Sajeevan.K

Serdar

unread,
Jan 25, 2021, 7:42:29 AMJan 25
to BeagleBoard
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ı:

Amit Goradia

unread,
May 19, 2021, 10:24:43 AMMay 19
to BeagleBoard
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

debian@beaglebone:~$ systemd-analyze
Startup finished in 1.690s (kernel) + 50.841s (userspace) = 52.532s
debian@beaglebone:~$ systemd-analyze blame
    1min 15.560s dev-mmcblk1p1.device
          8.459s generic-board-startup.service
          4.654s systemd-udev-trigger.service
          3.188s loadcpufreq.service
          2.620s networking.service
          2.157s keyboard-setup.service
          1.791s systemd-logind.service
          1.711s dnsmasq.service
          1.631s ssh.service
          1.529s rsyslog.service
          1.429s us...@1001.service
          1.418s systemd-journald.service
          1.204s cpufrequtils.service
          1.071s systemd-timesyncd.service
           918ms systemd-fsck-root.service
           597ms systemd-udevd.service
           528ms dev-mqueue.mount
           515ms sys-kernel-debug.mount
           495ms systemd-tmpfiles-setup-dev.service
           469ms systemd-tmpfiles-setup.service
           451ms systemd-sysctl.service
           417ms systemd-modules-load.service
           400ms systemd-user-sessions.service
           388ms sys-fs-fuse-connections.mount
           369ms systemd-journal-flush.service
           355ms slim.service
           324ms systemd-update-utmp.service
           311ms sys-kernel-config.mount
           303ms kmod-static-nodes.service
           300ms systemd-remount-fs.service
           238ms console-setup.service
           210ms systemd-random-seed.service
           140ms systemd-update-utmp-runlevel.service
debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-rt-r63 #1stretch SMP PREEMPT RT Fri May 14 16:42:35 UTC 2021 armv7l GNU/Linux

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.

Regards,
amit

John Dammeyer

unread,
May 19, 2021, 12:37:53 PMMay 19
to beagl...@googlegroups.com

Hi Amit,

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

 

debian@ebb:~$ systemd-analyze

Startup finished in 40.059s (kernel) + 1min 27.889s (userspace) = 2min 7.948s

 

debian@ebb:~$ systemd-analyze blame

    1min 47.177s dev-mmcblk0p1.device

    1min 13.819s generic-board-startup.service

 

debian@beaglebone:~$ uname -a

Linux beaglebone 4.19.94-ti-r63 #1buster SMP PREEMPT Fri May 14 16:42:32 UTC 2021 armv7l GNU/Linux

 

debian@beaglebone:~$ systemd-analyze

Startup finished in 26.608s (kernel) + 1min 32.506s (userspace) = 1min 59.114s

graphical.target reached after 1min 32.205s in userspace

 

debian@beaglebone:~$ systemd-analyze blame

    1min 20.997s generic-board-startup.service

     1min 4.519s dev-mmcblk0p1.device

         11.344s udisks2.service

 

--
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/989d9ca9-b8c8-424d-a88a-62cac4d4cc36n%40googlegroups.com.

Dennis Lee Bieber

unread,
May 19, 2021, 2:03:32 PMMay 19
to Beagleboard
On Wed, 19 May 2021 09:37:32 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer" <johnd-5o6dItLo...@public.gmane.org> wrote:

>Hi Amit,
>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
>
>debian@ebb:~$ systemd-analyze
>Startup finished in 40.059s (kernel) + 1min 27.889s (userspace) = 2min 7.948s
>
>debian@ebb:~$ systemd-analyze blame
> 1min 47.177s dev-mmcblk0p1.device
> 1min 13.819s generic-board-startup.service
>
>debian@beaglebone:~$ uname -a
>Linux beaglebone 4.19.94-ti-r63 #1buster SMP PREEMPT Fri May 14 16:42:32 UTC 2021 armv7l GNU/Linux
>
>debian@beaglebone:~$ systemd-analyze
>Startup finished in 26.608s (kernel) + 1min 32.506s (userspace) = 1min 59.114s
>graphical.target reached after 1min 32.205s in userspace
>
>debian@beaglebone:~$ systemd-analyze blame
> 1min 20.997s generic-board-startup.service
> 1min 4.519s dev-mmcblk0p1.device
> 11.344s udisks2.service
>

Just to add a data point: Buster IoT image on 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
Startup finished in 10.915s (kernel) + 1min 961ms (userspace) = 1min
11.877s
graphical.target reached after 1min 668ms in userspace

That's odd -- Did I leave the LXQT image in the board (I have uSD for
both IoT and LXQT)

debian@beaglebone:~$ systemd-analyze blame
51.745s generic-board-startup.service
40.798s dev-mmcblk0p1.device
4.064s nginx.service
3.587s systemd-udev-trigger.service

From DMESG one finds such ...

[ 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...@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.

debian@beaglebone:~$ systemd-analyze
Startup finished in 11.355s (kernel) + 1min 24.913s (userspace) = 1min
36.268s
graphical.target reached after 1min 24.632s in userspace
debian@beaglebone:~$ systemd-analyze blame
1min 15.551s generic-board-startup.service
1min 1.691s dev-mmcblk0p1.device
9.380s udisks2.service

DMESG output snippets

[ 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

SIXTY on PRU remoteproc stuff.


--
Dennis L Bieber

Amit Goradia

unread,
May 20, 2021, 8:08:41 AMMay 20
to BeagleBoard
On Wednesday, 19 May, 2021 at 10:07:53 pm UTC+5:30 jo...@autoartisans.com wrote:

Hi Amit,

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

Hi John,

I did not do much actually to get to 50s.
 replaced the kernel:

cd /opt/scripts/tools/

sudo su

git pull

./update_kernel.sh --ti-rt-channel --lts-4_19

removed wpasupplicant and connman and old kernel

sudo apt-get purge linux-image-4.14.108-ti-r134 wpasupplicant connman

debian@beaglebone:~$ systemd-analyze

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
          2.215s networking.service
          1.647s ssh.service
          1.396s us...@1000.service
          1.209s rsyslog.service
          1.189s systemd-journald.service
           999ms dnsmasq.service
           897ms cpufrequtils.service
           855ms systemd-timesyncd.service
           674ms systemd-fsck-root.service
           642ms systemd-logind.service
           505ms systemd-udevd.service
           445ms systemd-user-sessions.service
           408ms systemd-tmpfiles-setup-dev.service
           389ms systemd-update-utmp.service
           375ms hostapd.service
           365ms systemd-modules-load.service
           326ms dev-mqueue.mount
           324ms systemd-random-seed.service
           312ms sys-kernel-config.mount
           291ms systemd-tmpfiles-setup.service
           274ms sys-kernel-debug.mount
           236ms kmod-static-nodes.service
           231ms sys-fs-fuse-connections.mount
           200ms systemd-remount-fs.service
           190ms systemd-journal-flush.service
           185ms systemd-sysctl.service
           145ms systemd-update-utmp-runlevel.service
           130ms systemd-tmpfiles-clean.service

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. 

Hope that helps.

-amit

John Dammeyer

unread,
May 20, 2021, 12:33:10 PMMay 20
to beagl...@googlegroups.com

Thanks. Yes.  It does.

John

 

Robert Nelson

unread,
May 20, 2021, 1:31:42 PMMay 20
to Beagle Board
> removed wpasupplicant and connman and old kernel
>
> sudo apt-get purge linux-image-4.14.108-ti-r134 wpasupplicant connman
>
> debian@beaglebone:~$ systemd-analyze
>
> 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:

CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y

> 2.215s networking.service
> 1.647s ssh.service
> 1.396s us...@1000.service
> 1.209s rsyslog.service
> 1.189s systemd-journald.service
> 999ms dnsmasq.service
> 897ms cpufrequtils.service

Same as above..

> 855ms systemd-timesyncd.service
> 674ms systemd-fsck-root.service
> 642ms systemd-logind.service
> 505ms systemd-udevd.service
> 445ms systemd-user-sessions.service
> 408ms systemd-tmpfiles-setup-dev.service
> 389ms systemd-update-utmp.service
> 375ms hostapd.service

You nuked wpasupplicant, get rid of hostapd..

> 365ms systemd-modules-load.service
> 326ms dev-mqueue.mount
> 324ms systemd-random-seed.service
> 312ms sys-kernel-config.mount
> 291ms systemd-tmpfiles-setup.service
> 274ms sys-kernel-debug.mount
> 236ms kmod-static-nodes.service
> 231ms sys-fs-fuse-connections.mount
> 200ms systemd-remount-fs.service
> 190ms systemd-journal-flush.service
> 185ms systemd-sysctl.service
> 145ms systemd-update-utmp-runlevel.service
> 130ms systemd-tmpfiles-clean.service
>
> 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 (https://github.com/RobertCNelson/boot-scripts/issues/10)
>
> Hope that helps.

Amit Goradia

unread,
May 21, 2021, 3:02:08 AMMay 21
to BeagleBoard
Thanks a lot Robert. Your help is most appreciated.
I have implemented your suggestions and removed the following services
loadcpufreq.service
cpufrequtils.service
hostapd.service
My current boot time still ranges between 48s to 52s 

debian@beaglebone:~$ systemd-analyze
Startup finished in 1.751s (kernel) + 48.369s (userspace) = 50.120s
debian@beaglebone:~$ systemd-analyze blame
    1min 14.318s dev-mmcblk1p1.device
          9.419s generic-board-startup.service
          5.353s systemd-udev-trigger.service
          2.470s keyboard-setup.service
          2.438s networking.service
          2.423s ssh.service
          2.161s dnsmasq.service
          1.718s systemd-logind.service
          1.613s systemd-journald.service
          1.018s systemd-timesyncd.service
           969ms systemd-fsck-root.service
           730ms systemd-udevd.service
           595ms us...@1001.service
           589ms rsyslog.service
           549ms slim.service
           500ms sys-kernel-debug.mount
           488ms systemd-tmpfiles-setup-dev.service
           479ms systemd-update-utmp.service
           469ms dev-mqueue.mount
           456ms systemd-sysctl.service
           451ms systemd-tmpfiles-setup.service
           384ms systemd-modules-load.service
           380ms sys-kernel-config.mount
           352ms systemd-journal-flush.service
           344ms systemd-user-sessions.service
           319ms systemd-update-utmp-runlevel.service
           310ms systemd-random-seed.service
           284ms kmod-static-nodes.service
           257ms sys-fs-fuse-connections.mount
           250ms systemd-remount-fs.service
           227ms console-setup.service

Any suggestions to bring it down further?
I am using a X desktop with slim as the login manager with autologin on LCD.
From the generic board startup services, I am using network over USB (not the serial over USB and flash over USB) parts.
What else should I be able to nuke to get the time faster?

Regards,
-amit 

 

Amit Goradia

unread,
May 21, 2021, 6:25:32 AMMay 21
to BeagleBoard
Hi Robert,
I just realized that I need to use an overlayfs (via overlayroot) to protect the emmc / OS from crashing on sudden power off. 
Now overlaytroot needs the initrd image to work.
So I had to enable the /boot/initrd.img-4.19.94-ti-rt-r63 file.
Re-enablingthe initird file in /boot added about 48 to 50s to the kernel boot time ;-(
Any ideas on how to mitigate that? how to get the booting time down?
Thanks & Regards,
-amit

debian@beaglebone:/$ systemd-analyze
Startup finished in 58.454s (kernel) + 49.641s (userspace) = 1min 48.096s
debian@beaglebone:/$ systemd-analyze blame
    1min 21.167s dev-mmcblk1p1.device
         10.477s generic-board-startup.service
          5.278s systemd-udev-trigger.service
          2.907s networking.service
          2.684s ssh.service
          2.328s keyboard-setup.service
          1.940s dnsmasq.service
          1.661s systemd-journald.service
          1.101s systemd-user-sessions.service
           895ms systemd-udevd.service
           845ms us...@1001.service
           785ms systemd-random-seed.service
           766ms systemd-timesyncd.service
           754ms systemd-tmpfiles-setup-dev.service
           725ms systemd-modules-load.service
           670ms systemd-update-utmp.service
           657ms systemd-logind.service
           645ms sys-kernel-config.mount
           641ms sys-kernel-debug.mount
           603ms systemd-tmpfiles-setup.service
           572ms kmod-static-nodes.service
           518ms rsyslog.service
           515ms systemd-sysctl.service
           408ms systemd-remount-fs.service
           358ms slim.service
           351ms console-setup.service
           324ms systemd-journal-flush.service
           280ms sys-fs-fuse-connections.mount
           272ms systemd-tmpfiles-clean.service
           228ms systemd-update-utmp-runlevel.service
           223ms dev-mqueue.mount

Karishma Jaiswal

unread,
May 22, 2021, 4:10:55 PMMay 22
to BeagleBoard

Hi
I am working for the boot time optimization for the beagle bone green wireless board 
Now with some above mentioned suggestions, I am able to reduce the boot time from 90 sec to 45 sec.
But I want to further reduce it to 30 sec.
Please guide me the further points where I can optimize it.
The current detail of my board is as below 

Startup finished in 4.295s (kernel) + 38.147s (userspace) = 42.442s
ubuntu@arm:~$ systemd-analyze -blaim
systemd-analyze: invalid option -- 'b'
ubuntu@arm:~$ systemd-analyze blame
         25.275s console-setup.service
         17.904s dev-mmcblk1p1.device
         15.945s postfix.service
         12.165s generic-board-startup.service
          8.654s apache2.service
          7.635s systemd-logind.service
          6.160s avahi-daemon.service
          5.594s systemd-hwdb-update.service
          5.568s ondemand.service
          5.432s loadcpufreq.service
          4.968s bb-wl18xx-bluetooth.service
          4.578s led-status.service
          3.547s networking.service
          2.981s capemgr.service
          2.412s hostapd.service
          2.389s rsyslog.service
          2.073s cpufrequtils.service
          1.535s ssh.service
          1.477s systemd-user-sessions.service
          1.389s pppd-dns.service
          1.151s systemd-udev-trigger.service
          1.040s archive_log.service
          1.011s systemd-journal-flush.service
           979ms rc-local.service
           860ms brltty.service
           653ms keyboard-setup.service
           629ms systemd-journald.service
           609ms tacread-keymap.service
           499ms rename-bluetooth-hardware.service
           494ms systemd-update-utmp.service
           462ms systemd-udevd.service
           451ms resolvconf.service
           437ms dev-mqueue.mount
           437ms sys-kernel-debug.mount

Thanks 
Karishma Jaiswal 

Dennis Lee Bieber

unread,
May 22, 2021, 11:49:48 PMMay 22
to Beagleboard
On Sat, 22 May 2021 12:00:54 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Karishma Jaiswal
<karry.jaiswal-Re5J...@public.gmane.org> wrote:

> 15.945s postfix.service

Do you need a mail delivery service? http://www.postfix.org/ You have
scripts sending emails?

> 12.165s generic-board-startup.service
> 8.654s apache2.service

Do you need a web-server -- and if you do, does it have to be Apache?
Consider that nginx is installed as part of the normal Debian images.

> 7.635s systemd-logind.service
> 6.160s avahi-daemon.service

https://www.linux.com/topic/desktop/cleaning-your-linux-startup-process/
"""
avahi-daemon.service is supposed to provide zero-configuration network
discovery, and make it super-easy to find printers and other hosts on your
network. I always disable it and don’t miss it.
"""


> 5.594s systemd-hwdb-update.service
> 5.568s ondemand.service
> 5.432s loadcpufreq.service
> 4.968s bb-wl18xx-bluetooth.service
> 4.578s led-status.service
> 3.547s networking.service
> 2.981s capemgr.service
> 2.412s hostapd.service

Do you need to have the unit operate as a WiFi hotspot (Access Point)?
Note: not sure if the authentication feature is used for regular connection
/to/ an access point (WiFi Router). https://man.openbsd.org/hostapd.8

> 2.389s rsyslog.service
> 2.073s cpufrequtils.service
> 1.535s ssh.service
> 1.477s systemd-user-sessions.service
> 1.389s pppd-dns.service

Same web site:
"""
pppd-dns.service is a relic of the dim past. If you use dial-up Internet,
keep it. Otherwise, you don’t need it.

"""
> 1.151s systemd-udev-trigger.service
> 1.040s archive_log.service
> 1.011s systemd-journal-flush.service
> 979ms rc-local.service
> 860ms brltty.service
Ditto:
"""
brltty.service provides Braille device support, for example, Braille
displays.
"""

> 653ms keyboard-setup.service
> 629ms systemd-journald.service
> 609ms tacread-keymap.service

Can't find any information on "tacread" via Google... Nor via apt
search in Buster IoT release.

> 499ms rename-bluetooth-hardware.service
> 494ms systemd-update-utmp.service
> 462ms systemd-udevd.service
> 451ms resolvconf.service
> 437ms dev-mqueue.mount
> 437ms sys-kernel-debug.mount


--
Dennis L Bieber

Karishma Jaiswal

unread,
May 23, 2021, 10:19:56 PMMay 23
to BeagleBoard
@Dennis L Bieber Really thanks for your detailed explanation about the each services.
I also updated ubuntu from 16 to 18 and done some modification in the services. now my board's logs are as below   
My system should be working as station mode but may be future, we will add AP mode also.
I will also remove nginx services.  


ubuntu@beaglebone:~$ systemd-analyze blame
         51.048s dev-mmcblk1p1.device
         28.951s generic-board-startup.service
          6.550s led-status.service
          6.133s systemd-hwdb-update.service
          4.805s grub-common.service
          4.611s loadcpufreq.service
          3.244s nginx.service
          3.053s systemd-udev-trigger.service
          2.971s avahi-daemon.service
          2.099s ssh.service
          1.958s archive_log.service
          1.839s keyboard-setup.service
          1.548s rsyslog.service
          1.512s connman.service
          1.438s systemd-user-sessions.service
          1.404s wpa_supplicant.service
          1.315s ofono.service
          1.291s systemd-logind.service
          1.275s cpufrequtils.service
          1.253s tacread-keymap.service
           887ms systemd-timesyncd.service
           786ms us...@0.service
           685ms systemd-journald.service
           508ms kmod-static-nodes.service
           498ms dev-mqueue.mount
           487ms fake-hwclock.service
           469ms sys-kernel-config.mount
           459ms systemd-fsck-root.service
           422ms systemd-tmpfiles-setup-dev.service
           406ms systemd-modules-load.service
           401ms systemd-sysctl.service
           390ms systemd-tmpfiles-setup.service
           387ms setvtrgb.service
           350ms nvda.service
           341ms sys-fs-fuse-connections.mount


Also want to know that in ubuntu 18, why below two task taking so much time and how we can reduce it further to achieve the over all boot time as 30 sec. Any suggestion will help me. 

         51.048s dev-mmcblk1p1.device
         28.951s generic-board-startup.service


Thanks
Karishma Jaiswal

Robert Nelson

unread,
May 24, 2021, 11:42:08 AMMay 24
to Beagle Board
as long as you don't use usb-serial, usb-flash, or usb-networking on
the "OTG" USB port, you can nuke generic-board-startup.service

Regards,

robert.sty...@gmail.com

unread,
May 24, 2021, 12:26:44 PMMay 24
to BeagleBoard
Can you start these services later?

If you cannot just sleep, or hibinate to save power, and have to cold boot quickly.
I would hope for something like:

Initially
load the kernel loader
load the kernel
(load root file-system service)
(load IPC or network service)
load the turnkey application

Then as Needed
load device and file-system services


For a screen based turnkey app, you can only display a splash screen for a few seconds, before the user thinks it is broken, a bit longer for an animated splash screen. Imagine a car radio, something has happen immediately after power on (speaker click or LED indicator or screen backlight), then less than half a second "Tuning..." before music appears.

John Dammeyer

unread,
May 24, 2021, 1:32:32 PMMay 24
to beagl...@googlegroups.com

Just a totally irrelevant side note here. 

 

I finally found out why my Panasonic DMP-BD30 is so incredibly annoying on power up.  I can press the power button and the display lights up and a 'HELLO' message shows up instantly.  Then noises come from inside.  The 'HELLO' brightens and then changes to 'READING'.  About 20 seconds later the button to open the disk drawer finally works.

 

When went searching to see if there was a firmware upgrade I found out it was running Linux.

 

The inability of the disk drawer to be opened immediately is bad human factors engineering IMHO.  When a user turns on power they expect and should be rewarded with the drawer opening immediately if the eject button is pressed.  If it weren't running Linux but an RTOS or even just co-operative multi-threading the drawer operation wouldn't be delayed.  But that just isn't possible in a stock Linux system unless a special task is written that is loaded early and handles the tray.  Which would be very complicated I suspect and beyond the ability of the normal software engineer.

 

What is sad is we are seeing acceptance of this sort of poor behavior as perfectly alright.  Again IMHO.

 

John

 

 

 

 


Sent: May-24-21 9:27 AM
To: BeagleBoard

--

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.

Mark Lazarewicz

unread,
May 24, 2021, 1:58:22 PMMay 24
to beagl...@googlegroups.com
John 

Ohh boy you got me started now. My Verizon hotspot jetpack  (my 3rd purchase) resets very frequently sometimes 4 time's rebooting during important updates to my online database of vinyl. It also Freeze's up after 2 years intermittently for days. Linux and poor design. I suspect it's the wifi radio and software interface to Linux GUI. Has to be a serious bug to reset Chip. No watchdog to reset radio just goodbye reboot hello repeatedly.

Cheap design by some low payed QT PC programmer who's never seen an oscilloscope in his life is my guess.

I read them the riot act at Verizon. The Verizon manager was a computer science graduate who could not find a job 6 years ago.

Yes as consumer's we have to demand better and boycott bad engineering with our wallets.

Rant over

Mark

John Dammeyer

unread,
May 24, 2021, 2:34:58 PMMay 24
to beagl...@googlegroups.com

I agree. 

RantMode := TRUE;

It's not Linux per say which is an amazing environment that has brought so much. Not to mention the tremendous support from people like Robert.

 

But the side effect is that 16 to 18 seconds appears to be the fastest it can wake up which means it's not always the best solution for a product.  But in this world of Python and web based programming, embedded systems have taken a back seat.

 

If you were a new grad from what now tends to be called "Computer Engineering" would you take a job that offered $100K per year as a web designer or $60K developing embedded systems that required assembler knowledge?

 

So if your school used Linux and Raspberry Pi or Beagles as the learning environment and you were hired to develop a BluRay Player by Panasonic, would you pull out Microchip's MPLAB-X which you had never used along with a PIC32 or shoehorn in an ARM processor running Linux with all the support for online firmware upgrades and pre-written video decoding?  And if it takes 20 seconds to open the drawer just say so "who cares?".

 

When this BD30 player fails the first thing I will test on new hardware is how fast the drawer opens.  But I might also not have a choice…

RantMode := FALSE;

 

John

 

Dennis Lee Bieber

unread,
May 24, 2021, 3:50:41 PMMay 24
to Beagleboard
On Mon, 24 May 2021 11:34:41 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer" <johnd-5o6dItLo...@public.gmane.org> wrote:


>But the side effect is that 16 to 18 seconds appears to be the fastest it can wake up which means it's not always the best solution for a product. But in this world of Python and web based programming, embedded systems have taken a back seat.
>

https://www.adafruit.com/product/4064
Native system runs the CircuitPython interpreter in chip, with Python
application code files on the external flash (if you want base Arduino
behavior, you replace the in-chip CircuitPython with your Arduino sketch,
and use the external flash for data storage).

There are smaller Metro M4 Express (out of stock) and Metro M4 Express
AirLift (with on-board WiFi)

>If you were a new grad from what now tends to be called "Computer Engineering" would you take a job that offered $100K per year as a web designer or $60K developing embedded systems that required assembler knowledge?

Considering my ancient degree was "Computer Science" with an emphasis
on "systems" software rather than "business" software*... I'd probably have
qualified for the latter (at the time, as a new-hire at Lockheed Sunnyvale,
I got only $21K -- which had grown to $125K after 30 years) {And had a
defined benefit retirement plan, vs defined contribution... After layoff
moved to MI and manage a few years at GE Aviation -- my ("early
retirement") from Lockheed was nearly as much as GE paid!}




* "systems software" covered OS principles along with
compilers/linkers/etc, and language design. "business" had two terms of
statistics using SPSS (I'm sure these days they'd be using R [optimal],
Octave [as a backup -- Octave being a number cruncher/display tool, where R
includes more statistics testing built-in]), or maybe Python with SciPy and
or pandas extensions.
.


--
Dennis L Bieber

Dennis Lee Bieber

unread,
May 24, 2021, 4:11:57 PMMay 24
to Beagleboard
On Mon, 24 May 2021 09:26:44 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user
"robert.sty...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<robert.styles.forsyth-...@public.gmane.org> wrote:

>
>For a screen based turnkey app, you can only display a splash screen for a
>few seconds, before the user thinks it is broken, a bit longer for an
>animated splash screen. Imagine a car radio, something has happen
>immediately after power on (speaker click or LED indicator or screen
>backlight), then less than half a second "Tuning..." before music appears.
>
Probably not the best example. At best the "car radio" is running a
microcontroller -- not a microcomputer -- with maybe an RTOS at best. The
"radio application" is burned into the microcontroller flash memory, AND
RUNS out of that flash memory. There is no setting up RAM (virtual memory
mapping) as "RAM" in most microcontrollers is the general purpose register
bank. There may be secondary flash or EEPROM used to store user settings
(current volume/tone encoder position, stored station listing). A bigger
unit may include a spinning disk or "user flash" for storing MP3s, but the
core system doesn't have real "boot" phase.

Think Arduino Due, TIVA TM4C123 or TM4C1294, STM chips. ARM "M" cores,
not "A" cores.

On power-on, they start running the code burnt into the on-board flash
(and the first thing said code likely does is read the saved configuration
and command displays/output encoders to those values).

{Heck, most of the car is running off of microcontrollers with the single
application for each burned into flash. Can you imagine having to wait 60+
seconds for a Linux type OS to boot before you can turn the switch from ON
to START?}



--
Dennis L Bieber

John Dammeyer

unread,
May 24, 2021, 6:37:14 PMMay 24
to beagl...@googlegroups.com
> From: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] On Behalf Of Dennis Lee Bieber
> <robert.styles.forsyth-...@public.gmane.org> wrote:
>
> >
> >For a screen based turnkey app, you can only display a splash screen for a
> >few seconds, before the user thinks it is broken, a bit longer for an
> >animated splash screen. Imagine a car radio, something has happen
> >immediately after power on (speaker click or LED indicator or screen
> >backlight), then less than half a second "Tuning..." before music appears.
> >
> Probably not the best example. At best the "car radio" is running a
> microcontroller -- not a microcomputer -- with maybe an RTOS at best. The
> "radio application" is burned into the microcontroller flash memory, AND
> RUNS out of that flash memory. There is no setting up RAM (virtual memory
> mapping) as "RAM" in most microcontrollers is the general purpose register
> bank. There may be secondary flash or EEPROM used to store user settings
> (current volume/tone encoder position, stored station listing). A bigger
> unit may include a spinning disk or "user flash" for storing MP3s, but the
> core system doesn't have real "boot" phase.

I think the requirements concept is the issue. Too many times in the past I've run into projects where the client makes a choice on the architecture and then we have to make the project fit. Instead of a layout of the requirements and current/future capabilities as a design specification first. Then look around at what is available to fill that.

Now if boot time is an issue then what amount of time is acceptable. If it needs to be running in under 1 second then it doesn't matter how embedded the controller might be, a beagle or a pi running Linux is just not the tool for it. Sort of...

Volume of systems sold is another criteria as well as development time and longevity. The design decisions made if the device goes into a hard to access location will impact how it's designed and what's done with it. Etc.

I will state that waiting over two minutes for a Beagle to boot into Linux desktop mouse/keyboard/screen is unacceptable. Windows with a 640K 8088 or a Pentium-33MHz could create a graphical desktop way faster than a 1GHz Beagle with super fast SD card and 512MB of ram. From an end user perspective anything longer than 10 to 15 seconds just means it's not done right.

So I'd like to pose the question back to the original poster of this thread karry....@gmail.com. Why are you using a Beagle if you need fast boot times? What is it that the Beagle Green has that you need compared to something with an RTOS (Free RTOS for example). Why Linux?

I've been on both sides of the fence. I might have already posted the attached photo that shows a PiZeroW mounted onto a board that holds a PIC32, SuperCaps, RTC along with GPS module and SMS module. Two antennas: one for GPS, one for SMS messaging. And the connector to power and the vehicle CAN bus which requires instant on logging while the PiZero provides the file/networking infrastructure. The Pi is the SPI master, the PIC32 is the SPI slave. As long as the PIC has the RAM storage for all the CAN messages during the 18 second PiZeroW boot time all is good. It wasn’t worth the time to port Microchip SD card file system support or all the network stuff needed for cell net access. We only built 20.

And with respect to University days I'll deny I ever took Fortran or Cobal courses.........

John




STU-2s.jpg

Karishma Jaiswal

unread,
May 24, 2021, 11:31:52 PMMay 24
to BeagleBoard

Hi
>>>So I'd like to pose the question back to the original poster of this thread karry....@gmail.com. Why are you using a Beagle if you need fast boot times? 
it's an older product and we have to migrate it with enhanced peripheral. in the existing product, beagle bone board was used so as of now we can not change the board.
Recently we upgraded from ubuntu 16 to ubuntu 18. in ubuntu 16 total boot time was 30 sec only. But after ubuntu 18, boot time is taking too much time. 
Also we already showing "in progress" kind of message in our product, as "Tuning... " kind of message suggested. 

Thanks
Karishma Jaiswal

Karishma Jaiswal

unread,
May 24, 2021, 11:47:51 PMMay 24
to BeagleBoard
Thanks Robert, 
As suggested in link https://github.com/RobertCNelson/boot-scripts/issues/10 , I already applied the many changes.
In very initial, my system was taking total 90 sec as boot time which got reduced and now it's 54 sec approx. 

I also check to nuke generic-board-startup.service but not able to reduce further. can u suggest few example for which I need to reduce?
I removed the USB flash related things.
 not getting the exact reason why  51.048s dev-mmcblk1p1.device this is taking too much time and is there any way that we can reduce it?

Thanks
Karishma Jaiswal

Dennis Lee Bieber

unread,
May 25, 2021, 12:05:33 PMMay 25
to Beagleboard
On Mon, 24 May 2021 15:36:54 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer" <johnd-5o6dItLo...@public.gmane.org> wrote:


>I will state that waiting over two minutes for a Beagle to boot into Linux desktop mouse/keyboard/screen is unacceptable. Windows with a 640K 8088 or a Pentium-33MHz could create a graphical desktop way faster than a 1GHz Beagle with super fast SD card and 512MB of ram. From an end user perspective anything longer than 10 to 15 seconds just means it's not done right.

WfW barely qualified as a desktop. It was more of an application
manager running on top of MS-DOS.

My current desktop machine: 3.4GHz Intel i7-3770 with 12GB of RAM and
Windows 10, from a shutdown state took:

1:15 to reach the blue four-windows logo
2:00 to reach the Windows boot chime
2:25 to get to the login screen (and since my default user doesn't have a
password...)
2:55 to get to user desktop -- it was still loading various services for a
few more minutes after that

>
>So I'd like to pose the question back to the original poster of this thread karry.jaiswal-Re5JQEeQqe9fmgfxC/sS/w...@public.gmane.org Why are you using a Beagle if you need fast boot times? What is it that the Beagle Green has that you need compared to something with an RTOS (Free RTOS for example). Why Linux?
>
>
>And with respect to University days I'll deny I ever took Fortran or Cobal courses.........
>
It shows... <G>

COBOL COmmon Business Oriented Language
COBAL Generic Name: cyanocobalamin (vitamin b-12)


--
Dennis L Bieber

John Dammeyer

unread,
May 25, 2021, 12:51:07 PMMay 25
to beagl...@googlegroups.com
Let's do the math. One million users running WIN-10 software waiting say 2 minutes for usable desktop ready to perform. That's 2 million minutes. Or 33,333..333 hours or 4,166.666 days or 11.4 man-years of wasted time.

Do you think we can send an invoice to Bill Gates?
John


> -----Original Message-----
> From: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] On Behalf Of Dennis Lee Bieber
> --
> 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/jh7qagtbnnusf9aet6khtpo7aqarjqug94%404ax.com.

Dennis Lee Bieber

unread,
May 25, 2021, 1:00:42 PMMay 25
to Beagleboard
On Mon, 24 May 2021 20:47:42 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Karishma Jaiswal
<karry.jaiswal-Re5J...@public.gmane.org> wrote:


> not getting the exact reason why * 51.048s dev-mmcblk1p1.device *this is
>taking too much time and is there any way that we can reduce it?
>

Part of that may be tied to the flash memory device itself. Booting
from eMMC, my BBB came up with:

debian@beaglebone:~$ systemd-analyze blame
48.972s generic-board-startup.service
48.587s dev-mmcblk1p1.device
3.739s nginx.service

But booting from a uSD card (my normal mode to avoid "wearout" of the eMMC)
showed:

debian@beaglebone:~$ systemd-analyze blame
49.889s generic-board-startup.service
39.657s dev-mmcblk0p1.device
4.126s nginx.service

... The uSD was 10 seconds faster, even though that is an 8GB uSD card vs
the 4GB eMMC.

I couldn't find anything confirming if there is some sort of boot time
fsck being run.

debian@beaglebone:~$ sudo tune2fs -l /dev/mmcblk0p1
tune2fs 1.44.5 (15-Dec-2018)
Filesystem volume name: rootfs
Last mounted on: /
<SNIP>
Last mount time: Tue May 25 12:34:35 2021
Last write time: Tue May 25 12:34:31 2021
Mount count: 132
Maximum mount count: -1
Last checked: Wed Aug 19 21:34:49 2020
Check interval: 0 (<none>)
<SNIP>
debian@beaglebone:~$

Those seem to imply that no fsck is run at boot time.



--
Dennis L Bieber

Karishma Jaiswal

unread,
May 27, 2021, 2:22:39 PMMay 27
to BeagleBoard
Hi
Now my boot time, [from the power up to console message display] is around 40 sec.
I want to reduce it further till 25 sec. below are the existing dmesg log of my beaglebone board.

ubuntu@beaglebone:~$ dmesg 
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.19.94-ti-r36 (voodoo@w1-imx6q-wandboard-2gb) (gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)) #1bionic SMP PREEMPT Mon Mar 2 15:55:39 UTC 2020
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: TI AM335x BeagleBone Green Wireless
[    0.000000] Memory policy: Data cache writeback
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.
[    0.000000] cma: Reserved 48 MiB at 0x9c800000
[    0.000000] On node 0 totalpages: 130560
[    0.000000]   Normal zone: 1148 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 130560 pages, LIFO batch:31
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] AM335X ES2.1 (sgx neon)
[    0.000000] random: get_random_bytes called from start_kernel+0xa0/0x508 with crng_init=0
[    0.000000] percpu: Embedded 17 pages/cpu s39628 r8192 d21812 u69632
[    0.000000] pcpu-alloc: s39628 r8192 d21812 u69632 alloc=17*4096
[    0.000000] pcpu-alloc: [0] 0 
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 129412
[    0.000000] Kernel command line: console=ttyO0,115200n8 bone_capemgr.enable_partno=BB-UART2 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 445240K/522240K available (13312K kernel code, 1156K rwdata, 4444K rodata, 1024K init, 355K bss, 27848K reserved, 49152K cma-reserved, 0K highmem)
[    0.000000] Virtual kernel memory layout:
                   vector  : 0xffff0000 - 0xffff1000   (   4 kB)
                   fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
                   vmalloc : 0xe0000000 - 0xff800000   ( 504 MB)
                   lowmem  : 0xc0000000 - 0xdfe00000   ( 510 MB)
                   pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
                   modules : 0xbf000000 - 0xbfe00000   (  14 MB)
                     .text : 0x(ptrval) - 0x(ptrval)   (14304 kB)
                     .init : 0x(ptrval) - 0x(ptrval)   (1024 kB)
                     .data : 0x(ptrval) - 0x(ptrval)   (1157 kB)
                      .bss : 0x(ptrval) - 0x(ptrval)   ( 356 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] ftrace: allocating 42638 entries in 126 pages
[    0.000000] rcu: Preemptible hierarchical RCU implementation.
[    0.000000] rcu: RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[    0.000000] Tasks RCU enabled.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] IRQ: Found an INTC at 0x(ptrval) (revision 5.0) with 128 interrupts
[    0.000000] OMAP clockevent source: timer2 at 24000000 Hz
[    0.000015] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
[    0.000032] clocksource: timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
[    0.000041] OMAP clocksource: timer1 at 24000000 Hz
[    0.000776] timer_probe: no matching timers found
[    0.001015] Console: colour dummy device 80x30
[    0.001045] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
[    0.001049] This ensures that you still see kernel messages. Please
[    0.001053] update your kernel commandline.
[    0.001113] Calibrating delay loop... 995.32 BogoMIPS (lpj=1990656)
[    0.046823] pid_max: default: 32768 minimum: 301
[    0.047115] Security Framework initialized
[    0.047128] Yama: becoming mindful.
[    0.047277] AppArmor: AppArmor initialized
[    0.047390] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.047401] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.048512] CPU: Testing write buffer coherency: ok
[    0.048574] CPU0: Spectre v2: using BPIALL workaround
[    0.049060] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[    0.070931] Setting up static identity map for 0x80100000 - 0x80100060
[    0.078845] rcu: Hierarchical SRCU implementation.
[    0.090150] EFI services will not be available.
[    0.094854] smp: Bringing up secondary CPUs ...
[    0.094868] smp: Brought up 1 node, 1 CPU
[    0.094878] SMP: Total of 1 processors activated (995.32 BogoMIPS).
[    0.094885] CPU: All CPU(s) started in SVC mode.
[    0.096625] devtmpfs: initialized
[    0.111301] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    0.111957] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.111980] futex hash table entries: 256 (order: 2, 16384 bytes)
[    0.115993] xor: measuring software checksum speed
[    0.154830]    arm4regs  :  1217.000 MB/sec
[    0.194819]    8regs     :  1091.000 MB/sec
[    0.234817]    32regs    :  1166.000 MB/sec
[    0.274817]    neon      :  1674.000 MB/sec
[    0.274823] xor: using function: neon (1674.000 MB/sec)
[    0.274842] pinctrl core: initialized pinctrl subsystem
[    0.276224] NET: Registered protocol family 16
[    0.282409] DMA: preallocated 1024 KiB pool for atomic coherent allocations
[    0.320970] l4_wkup_cm:clk:0010:0: failed to disable
[    0.361185] audit: initializing netlink subsys (disabled)
[    0.362484] cpuidle: using governor menu
[    0.366950] audit: type=2000 audit(0.352:1): state=initialized audit_enabled=0 res=1
[    0.371356] OMAP GPIO hardware version 0.1
[    0.372222] GPIO line 61 (LS_BUF_EN) hogged as output/high
[    0.374382] GPIO line 112 (MCASP0_AHCLKR) hogged as output/low
[    0.385181] No ATAGs?
[    0.385193] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.410995] raid6: using algorithm neonx8 gen() 0 MB/s
[    0.411007] raid6: .... xor() 0 MB/s, rmw enabled
[    0.411014] raid6: using neon recovery algorithm
[    0.418374] edma 49000000.edma: TI EDMA DMA engine driver
[    0.422470] SCSI subsystem initialized
[    0.426957] libata version 3.00 loaded.
[    0.427279] usbcore: registered new interface driver usbfs
[    0.427340] usbcore: registered new interface driver hub
[    0.427468] usbcore: registered new device driver usb
[    0.429713] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz
[    0.429985] media: Linux media interface: v0.10
[    0.430038] videodev: Linux video capture interface: v2.00
[    0.430181] pps_core: LinuxPPS API ver. 1 registered
[    0.430188] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giom...@linux.it>
[    0.430209] PTP clock support registered
[    0.430982] omap-mailbox 480c8000.mailbox: omap mailbox rev 0x400
[    0.435207] Advanced Linux Sound Architecture Driver Initialized.
[    0.436017] NetLabel: Initializing
[    0.436028] NetLabel:  domain hash size = 128
[    0.436032] NetLabel:  protocols = UNLABELED CIPSOv4 CALIPSO
[    0.436135] NetLabel:  unlabeled traffic allowed by default
[    0.437305] clocksource: Switched to clocksource timer1
[    0.602117] VFS: Disk quotas dquot_6.6.0
[    0.602222] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.603114] AppArmor: AppArmor Filesystem Enabled
[    0.615534] NET: Registered protocol family 2
[    0.616616] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes)
[    0.616650] TCP established hash table entries: 4096 (order: 2, 16384 bytes)
[    0.616692] TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
[    0.616749] TCP: Hash tables configured (established 4096 bind 4096)
[    0.616880] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    0.616904] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    0.617128] NET: Registered protocol family 1
[    0.630527] RPC: Registered named UNIX socket transport module.
[    0.630537] RPC: Registered udp transport module.
[    0.630542] RPC: Registered tcp transport module.
[    0.630547] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.632068] hw perfevents: enabled with armv7_cortex_a8 PMU driver, 5 counters available
[    0.634849] Initialise system trusted keyrings
[    0.635238] workingset: timestamp_bits=14 max_order=17 bucket_order=3
[    0.642604] zbud: loaded
[    0.650066] NFS: Registering the id_resolver key type
[    0.650131] Key type id_resolver registered
[    0.650137] Key type id_legacy registered
[    0.650154] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    0.650522] fuse init (API version 7.27)
[    0.661042] Key type asymmetric registered
[    0.661056] Asymmetric key parser 'x509' registered
[    0.661158] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 244)
[    0.665770] io scheduler noop registered
[    0.665782] io scheduler deadline registered
[    0.666104] io scheduler cfq registered (default)
[    0.666115] io scheduler mq-deadline registered
[    0.668661] pinctrl-single 44e10800.pinmux: 142 pins, size 568
[    0.670251] gpio-of-helper ocp:cape-universal: ready
[    0.672937] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle
[    0.675145] Serial: 8250/16550 driver, 6 ports, IRQ sharing disabled
[    0.678923] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 38, base_baud = 3000000) is a 8250
[    0.695842] console [ttyS0] enabled
[    0.697066] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 39, base_baud = 3000000) is a 8250
[    0.698356] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 40, base_baud = 3000000) is a 8250
[    0.701031] omap_rng 48310000.rng: Random Number Generator ver. 20
[    0.705490] random: fast init done
[    0.705828] random: crng init done
[    0.825090] libphy: Fixed MDIO Bus: probed
[    0.827046] usbcore: registered new interface driver smsc95xx
[    0.827927] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.827976] ehci-platform: EHCI generic platform driver
[    0.828185] ehci-omap: OMAP-EHCI Host Controller driver
[    0.828728] usbcore: registered new interface driver usb-storage
[    0.831465] am335x-phy-driver 47401300.usb-phy: 47401300.usb-phy supply vcc not found, using dummy regulator
[    0.831640] am335x-phy-driver 47401300.usb-phy: Linked as a consumer to regulator.0
[    0.834523] am335x-phy-driver 47401b00.usb-phy: 47401b00.usb-phy supply vcc not found, using dummy regulator
[    0.834700] am335x-phy-driver 47401b00.usb-phy: Linked as a consumer to regulator.0
[    0.838043] musb-hdrc musb-hdrc.1: MUSB HDRC host driver
[    0.838084] musb-hdrc musb-hdrc.1: new USB bus registered, assigned bus number 1
[    0.838448] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
[    0.838459] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.838467] usb usb1: Product: MUSB HDRC host driver
[    0.838474] usb usb1: Manufacturer: Linux 4.19.94-ti-r36 musb-hcd
[    0.838481] usb usb1: SerialNumber: musb-hdrc.1
[    0.839293] hub 1-0:1.0: USB hub found
[    0.839355] hub 1-0:1.0: 1 port detected
[    0.850608] omap_rtc 44e3e000.rtc: already running
[    0.851292] omap_rtc 44e3e000.rtc: registered as rtc0
[    0.852580] i2c /dev entries driver
[    0.853253] Driver for 1-wire Dallas network protocol.
[    0.855645] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    0.856124] softdog: initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0)
[    0.857655] cpuidle: enable-method property 'ti,am3352' found operations
[    0.858255] sdhci: Secure Digital Host Controller Interface driver
[    0.858262] sdhci: Copyright(c) Pierre Ossman
[    0.858792] omap_gpio 44e07000.gpio: Could not set line 6 debounce to 200000 microseconds (-22)
[    0.858803] omap_hsmmc 48060000.mmc: Got CD GPIO
[    0.859422] omap_hsmmc 48060000.mmc: Linked as a consumer to regulator.2
[    0.886849] omap_hsmmc 481d8000.mmc: Linked as a consumer to regulator.2
[    0.910663] omap_hsmmc 47810000.mmc: Linked as a consumer to regulator.1
[    0.951112] mmc1: new high speed MMC card at address 0001
[    0.956478] mmcblk1: mmc1:0001 Q2J54A 3.64 GiB 
[    0.957105] mmcblk1boot0: mmc1:0001 Q2J54A partition 1 2.00 MiB
[    0.957836] mmcblk1boot1: mmc1:0001 Q2J54A partition 2 2.00 MiB
[    0.958197] mmcblk1rpmb: mmc1:0001 Q2J54A partition 3 512 KiB, chardev (242:0)
[    0.964213]  mmcblk1: p1
[    1.013738] sdhci-pltfm: SDHCI platform and OF driver helper
[    1.015773] ledtrig-cpu: registered to indicate activity on CPUs
[    1.016492] omap-aes 53500000.aes: OMAP AES hw accel rev: 3.2
[    1.016740] omap-aes 53500000.aes: will run requests pump with realtime priority
[    1.019406] omap-sham 53100000.sham: hw accel on OMAP rev 4.3
[    1.023051] hidraw: raw HID events driver (C) Jiri Kosina
[    1.023419] omap_hsmmc 47810000.mmc: card claims to support voltages below defined range
[    1.024017] usbcore: registered new interface driver usbhid
[    1.024024] usbhid: USB HID core driver
[    1.025008] remoteproc remoteproc0: wkup_m3 is available
[    1.030746] gnss: GNSS driver registered with major 239
[    1.037253] mmc2: new high speed SDIO card at address 0001
[    1.038327] wireguard: WireGuard 0.0.20191219 loaded. See www.wireguard.com for information.
[    1.038337] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Ja...@zx2c4.com>. All Rights Reserved.
[    1.039586] NET: Registered protocol family 10
[    1.047812] Segment Routing with IPv6
[    1.047947] mip6: Mobile IPv6
[    1.047966] NET: Registered protocol family 17
[    1.048080] Key type dns_resolver registered
[    1.048087] mpls_gso: MPLS GSO support
[    1.048462] ThumbEE CPU extension supported.
[    1.048477] Registering SWP/SWPB emulation handler
[    1.048487] omap_voltage_late_init: Voltage driver support not added
[    1.055664] PM: Cannot get wkup_m3_ipc handle
[    1.061757] registered taskstats version 1
[    1.061767] Loading compiled-in X.509 certificates
[    1.061905] zswap: loaded using pool lzo/zbud
[    1.064948] Btrfs loaded, crc32c=crc32c-generic
[    1.065057] AppArmor: AppArmor sha1 policy hashing enabled
[    1.118881] tps6521x_pwrbutton tps65217-pwrbutton: DMA mask not set
[    1.119706] input: tps65217_pwr_but as /devices/platform/ocp/44e0b000.i2c/i2c-0/0-0024/tps65217-pwrbutton/input/input0
[    1.120303] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[    1.121169] at24 0-0050: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    1.121373] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[    1.123168] remoteproc remoteproc0: powering up wkup_m3
[    1.123288] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217168
[    1.126686] remoteproc remoteproc0: remote processor wkup_m3 is now up
[    1.126705] wkup_m3_ipc 44e11324.wkup_m3_ipc: CM3 Firmware Version = 0x193
[    1.127064] cpu cpu0: Linked as a consumer to regulator.4
[    1.127169] cpu cpu0: Dropping the link to regulator.4
[    1.127736] cpu cpu0: Linked as a consumer to regulator.4
[    1.129507] PM: bootloader does not support rtc-only!
[    1.130607] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 00:46:28 UTC (946687588)
[    1.131393] ALSA device list:
[    1.131400]   No soundcards found.
[    1.147174] EXT4-fs (mmcblk1p1): mounted filesystem with ordered data mode. Opts: (null)
[    1.147281] VFS: Mounted root (ext4 filesystem) readonly on device 179:1.
[    1.148279] devtmpfs: mounted
[    1.154451] Freeing unused kernel memory: 1024K
[    1.155183] Run /sbin/init as init process
[    1.245447] usb 1-1: new high-speed USB device number 2 using musb-hdrc
[    1.395341] usb 1-1: New USB device found, idVendor=05e3, idProduct=0610, bcdDevice=32.98
[    1.395358] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    1.395366] usb 1-1: Product: USB2.0 Hub
[    1.396911] hub 1-1:1.0: USB hub found
[    1.397267] hub 1-1:1.0: 4 ports detected
[    1.506647] systemd[1]: System time before build time, advancing clock.
[    1.628501] systemd[1]: systemd 237 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[    1.629230] systemd[1]: Detected architecture arm.
[    1.653820] systemd[1]: Set hostname to <beaglebone>.
[    1.689472] usb 1-1.1: new low-speed USB device number 3 using musb-hdrc
[    1.796466] usb 1-1.1: New USB device found, idVendor=413c, idProduct=2113, bcdDevice= 1.08
[    1.796483] usb 1-1.1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[    1.796491] usb 1-1.1: Product: Dell KB216 Wired Keyboard
[    1.803948] input: Dell KB216 Wired Keyboard as /devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/usb1/1-1/1-1.1/1-1.1:1.0/0003:413C:2113.0001/input/input1
[    1.862305] hid-generic 0003:413C:2113.0001: input,hidraw0: USB HID v1.11 Keyboard [Dell KB216 Wired Keyboard] on usb-musb-hdrc.1-1.1/input0
[    1.869513] input: Dell KB216 Wired Keyboard System Control as /devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/usb1/1-1/1-1.1/1-1.1:1.1/0003:413C:2113.0002/input/input2
[    1.929785] input: Dell KB216 Wired Keyboard Consumer Control as /devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/usb1/1-1/1-1.1/1-1.1:1.1/0003:413C:2113.0002/input/input3
[    1.930333] hid-generic 0003:413C:2113.0002: input,hidraw1: USB HID v1.11 Device [Dell KB216 Wired Keyboard] on usb-musb-hdrc.1-1.1/input1
[    2.009546] usb 1-1.4: new low-speed USB device number 4 using musb-hdrc
[    2.089551] usb 1-1.4: device descriptor read/64, error -32
[    2.285481] usb 1-1.4: device descriptor read/64, error -32
[    2.481472] usb 1-1.4: new low-speed USB device number 5 using musb-hdrc
[    2.561452] usb 1-1.4: device descriptor read/64, error -32
[    2.753470] usb 1-1.4: device descriptor read/64, error -32
[    2.828438] systemd[1]: Created slice User and Session Slice.
[    2.828974] systemd[1]: Reached target Swap.
[    2.829845] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[    2.831934] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[    2.832168] systemd[1]: Reached target Remote File Systems.
[    2.834084] systemd[1]: Created slice System Slice.
[    2.834903] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[    2.865868] usb 1-1-port4: attempt power cycle
[    3.469468] usb 1-1.4: new low-speed USB device number 6 using musb-hdrc
[    3.885496] usb 1-1.4: device not accepting address 6, error -32
[    3.989483] usb 1-1.4: new low-speed USB device number 7 using musb-hdrc
[    4.289533] EXT4-fs (mmcblk1p1): re-mounted. Opts: errors=remount-ro
[    4.405419] usb 1-1.4: device not accepting address 7, error -32
[    4.435153] usb 1-1-port4: unable to enumerate USB device
[    4.615016] systemd-journald[144]: Received request to flush runtime journal from PID 1
[   13.060804] Bluetooth: Core ver 2.22
[   13.060968] NET: Registered protocol family 31
[   13.060978] Bluetooth: HCI device and connection manager initialized
[   13.061006] Bluetooth: HCI socket layer initialized
[   13.061020] Bluetooth: L2CAP socket layer initialized
[   13.061076] Bluetooth: SCO socket layer initialized
[   14.352453] input: BRLTTY 5.4 Linux Screen Driver Keyboard as /devices/virtual/input/input4
[   31.721632] wlan-en-regulator: disabling
[   46.898563] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[   46.908629] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[   48.838829] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
[   48.872572] wlcore: loaded
[   49.474429] wlcore: PHY firmware version: Rev 8.2.0.0.240
[   49.518365] wlcore: firmware booted (Rev 8.9.0.0.76)
[   49.534132] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   51.541997] wlan0: authenticate with 50:2b:73:2f:60:81
[   51.548875] wlan0: send auth to 50:2b:73:2f:60:81 (try 1/3)
[   51.586392] wlan0: authenticated
[   51.589980] wlan0: associate with 50:2b:73:2f:60:81 (try 1/3)
[   51.599824] wlan0: RX AssocResp from 50:2b:73:2f:60:81 (capab=0xc11 status=0 aid=9)
[   51.610042] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   51.615269] wlan0: associated
[   51.697657] cryptd: max_cpu_qlen set to 1000
[   51.773890] wlcore: Association completed.
[   62.719318] using random self ethernet address
[   62.719336] using random host ethernet address
[   63.027125] using random self ethernet address
[   63.027142] using random host ethernet address
[   63.193779] usb0: HOST MAC e4:15:f6:f5:8a:0d
[   63.197119] usb0: MAC e4:15:f6:f5:8a:0c
[   63.207435] usb1: HOST MAC e4:15:f6:f5:8a:0f
[   63.208192] usb1: MAC e4:15:f6:f5:8a:10
[   63.359203] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready
[   63.649893] configfs-gadget gadget: high-speed config #1: c
[   63.651463] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
[   65.017957] Bluetooth: HCI UART driver ver 2.3
[   65.017977] Bluetooth: HCI UART protocol H4 registered
[   65.019448] Bluetooth: HCI UART protocol LL registered
[   65.019458] Bluetooth: HCI UART protocol ATH3K registered
[   65.019595] Bluetooth: HCI UART protocol Three-wire (H5) registered
[   65.883284] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   65.883300] Bluetooth: BNEP filters: protocol multicast
[   65.884153] Bluetooth: BNEP socket layer initialized
[   66.276579] Bluetooth: RFCOMM TTY layer initialized
[   66.276624] Bluetooth: RFCOMM socket layer initialized
[   66.276682] Bluetooth: RFCOMM ver 1.11
 




Can I further reduce the bootup time with few more second?
At-least console message should get display withing 25 sec.?
Can I change any initialization sequence so that I can get the booting message more early ?

Thanks
Karishma Jaiswal  

Karishma Jaiswal

unread,
May 30, 2021, 2:51:36 PMMay 30
to BeagleBoard
@Robet Nelson

Can u suggest any way to change my application as currently my application is getting call from .bashrc file and now it's taking around 35 sec to get execute.
Some how can I call the .bashrc file bit faster?  
this will really help to reduce the boot time.

Thanks
Karishma Jaiswal

Dennis Lee Bieber

unread,
May 30, 2021, 3:44:47 PMMay 30
to Beagleboard
On Sun, 30 May 2021 11:51:27 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Karishma Jaiswal
<karry.jaiswal-Re5J...@public.gmane.org> wrote:


>Can u suggest any way to change my application as currently my application
>is getting call from .bashrc file and now it's taking around 35 sec to get
>execute.
>Some how can I call the .bashrc file bit faster?
>this will really help to reduce the boot time.

Since .bashrc is a SHELL CONFIGURATION file, it gets run when a BASH
shell is opened. So how are you getting to a bash shell? (It is vaguely
possible you have some script being started by systemd, or a @reboot
crontab entry, which specifies that the bash shell is to be used).

Bash shell/command interpreter won't be available until most of the OS
has booted.


--
Dennis L Bieber

Reply all
Reply to author
Forward
0 new messages