Reducing Boottime in Beaglebone Black

[ksajee...@gmail.com]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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  

https://eewiki.net/display/linuxonarm/BeagleBone+Black.

Thanks & Regards,

Sajeevan.K

[Robert Nelson]

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]

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]

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]

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]

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]

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]

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.

Started from  a console Image : https://rcn-ee.com/rootfs/bb.org/testing/2020-05-02/stretch-console/bone-eMMC-flasher-debian-9.12-console-armhf-2020-05-02-1gb.img.xz

 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. 

Some ideas can be found here (https://github.com/RobertCNelson/boot-scripts/issues/10)

Hope that helps.

-amit

[John Dammeyer]

Thanks. Yes.  It does.

John

 

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/fde7a746-4ae2-41c8-aa2b-3791e534a176n%40googlegroups.com.

[Robert Nelson]

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

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]

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]

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]

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]

@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]

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]

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]

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

 

 

 

 

From: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] On Behalf Of robert.sty...@gmail.com

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/f25766a9-4032-4466-a3b5-e42a5df485d5n%40googlegroups.com.

[Mark Lazarewicz]

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

Sent from Yahoo Mail on Android

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/00b701d750c2%24bb5953b0%24320bfb10%24%40autoartisans.com.

[John Dammeyer]

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

 

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1958141964.2239749.1621879085902%40mail.yahoo.com.

[Dennis Lee Bieber]

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]

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]

> 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

[Karishma Jaiswal]

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]

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]

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]

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]

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]

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]

@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]

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