BUG: Flashing Beaglebone Black with Micro SD Card

Hello,

I am developing a custom Beaglebone image which I want to deploy on to many other Beaglebones. The easiest way of doing that is using the beaglebone-black-make-microSD-flasher-from-eMMC.sh script provided with every Beaglebone.
That has also worked fine so far until I started deleting /boot/initrd.img-4.19.94-ti-r*.
I need my Beaglebone to boot as fast as possible and I have found out, that by removing the initrd.img-4.19.94-ti-r* file, the boot time is reduced by over 10 seconds.
@RobertCNelson has also stated, that this file is not necessarily needed (If I understood that correctly)

Because the shell script creating the micro sd flasher also creates the initrd file, I have written a script, that removes the file if it is present.
But now if I flash a SD card with my image, the first beaglebone I want to overwrite, is flashed successfully. But the second one, won’t flash anymore. (Error: We don’t know how to reset the leds as we are not a BBB compatible device)

Why does the script think, that it isn’t a Beaglebone anymore?

Why does it work the first time, but fail the times after? The micro SD shouln’t be edited, when flashing a Beaglebone or am I wrong? I am confused.

Thanks in Advance.

Regards,

Swizz

Flasher needs the initrd, please submit patches to work around issues without it…

side note, fixing things so this workaround isn’t needed:

root@BeagleBone:~# uname -r
5.10.59-ti-r22

root@BeagleBone:~# systemd-analyze 
Startup finished in 15.061s (kernel) + 30.619s (userspace) = 45.680s 
graphical.target reached after 30.194s in userspace

no initrd
root@BeagleBone:~# systemd-analyze 
Startup finished in 9.765s (kernel) + 31.619s (userspace) = 41.384s 
graphical.target reached after 31.082s in userspace

Regards,

Speed of booting a BBB has been a grumble of mine for quite some time.

debian@ebb:~$ uname -r
4.19.94-ti-r68
debian@ebb:~$ systemd-analyze
Startup finished in 24.316s (kernel) + 1min 33.552s (userspace) = 1min 57.868s
graphical.target reached after 1min 33.271s in userspace
debian@ebb:~$

Compared to a Pi4 which granted has more cores but this big a difference?

pi@linuxcnc:~ $ uname -r
4.19.71-rt24-v7l+
pi@linuxcnc:~ $ systemd-analyze
Startup finished in 2.029s (kernel) + 18.810s (userspace) = 20.840s
graphical.target reached after 18.715s in userspace
pi@linuxcnc:~ $

Why?

Well RPI has a Full time Kernel Developers and Staff…

Disable gadget loading and all the udev rules for config-pin and loading “cape-universal”…

Image i’m developing: Index of /rootfs/debian-armhf/2021-10-05

Regards,

@RobertCNelson They aren’t that good at it!

For a project a few years ago my colleagues in the UK couldn’t get the boot time lower than about 16 seconds IIRC. We needed the Hydrogen powered vehicle CAN messages from the moment the ignition key applied power to the system. So I designed a PIC32 to read, timestamp, store and then upload to the PiZeroW when it was finally awake. Included in the messages to the Pi were also GPS which gave the Pi the correct TOD.

In the photo below the PIC32 is underneath the PizeroW. Beside it Cell Modem and GPS.

6STU v1 Assembled

My Panasonic BlueRay Player also runs with Linux under the covers. Very annoying to power it up and have to wait almost 20 seconds before it responds to the drawer open button.

Another user pointed out haveged is no longer reguired on v5.6.x kernel’s, we originally installed this service back in v4.14.x when the crng kernel generation got massivily slowed down, which haveged fixed…

So in Bullseye, with v5.6.+ kernels, just nuke haveaged: then userspace bootup gains another 10 seconds:

root@BeagleBone:~# uname -r
5.10.65-ti-r23

Pre:

root@BeagleBone:~# systemd-analyze 
Startup finished in 14.926s (kernel) + 30.569s (userspace) = 45.496s 
graphical.target reached after 30.157s in userspace

Post:

root@BeagleBone:~# systemd-analyze 
Startup finished in 14.960s (kernel) + 19.538s (userspace) = 34.498s 
graphical.target reached after 19.243s in userspace

Regards,