Raspberry Startup Zeiten - hat da jemand Erfahrung/ungefähre Messungen?

[Martin M. (capiman)]

Hallo,

ich habe einen Raspberry Pi (CM3+) im Einsatz (bin aber recht neu mit 
Raspi unterwegs). Ich hab die serielle Console in Betrieb genommen.
Wenn ich Spannung anlege, dann sehe ich erst einmal 20s lang nichts,
dann beginnen die Ausgaben des Kernel:

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.19.118-v7+ (dom@buildbot) (gcc version 
4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1311 SMP Mon Apr 
27 14:21:24 BST 2020
[    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), 
cr=10c5383d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[    0.000000] OF: fdt: Machine model: Raspberry Pi Compute Module 3 
Plus Rev 1.0
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] cma: Reserved 8 MiB at 0x3ac00000
...
[    4.004645] systemd[1]: Listening on Journal Socket.
[    4.024596] systemd[1]: Mounting Kernel Debug File System...
[    4.042422] systemd[1]: Starting Set the console keyboard layout...
[    4.067995] systemd[1]: Starting Restore / save the current clock...

Dann dauert es wieder so um die 25 Sekunden, bis dann endlich der Login 
prompt erscheint.
Ich boote von einer uSD Karte.

Sind diese langen Zeiten normal? Was macht er da?
Oder kann ich vielleicht noch mehr Debug-Infos einschalten,
dass ich sehe, was er in der Zeit macht?

Oder kann ich die Zeit reduzieren, z.B. durch Schalter,
die gewisse Hardware aktivieren/deaktivieren, die ich aktuell nicht
verwende?

[Jack V. (jackv)]

›systemd-analyze blame‹

[Martin M. (capiman)]

pi@raspberrypi:~$ systemd-analyze blame
         12.786s dhcpcd.service
          1.866s dev-mmcblk0p2.device
           640ms keyboard-setup.service
           614ms systemd-timesyncd.service
           602ms 
systemd-fsck@dev-disk-by\x2dpartuuid-1ac1fab0\x2d01.service
           469ms dphys-swapfile.service
           450ms raspi-config.service
           448ms systemd-udev-trigger.service
           444ms systemd-logind.service
           434ms avahi-daemon.service
           363ms wpa_supplicant.service
           352ms networking.service
           326ms systemd-fsck-root.service
           297ms [e-mail]
           293ms systemd-journald.service
           271ms rsyslog.service
           238ms alsa-restore.service
           225ms ssh.service
           211ms rng-tools.service
           184ms systemd-remount-fs.service
           178ms systemd-udevd.service
           170ms sys-kernel-debug.mount
           149ms systemd-modules-load.service
           148ms fake-hwclock.service
           134ms rpi-eeprom-update.service
           124ms systemd-sysctl.service
           116ms dev-mqueue.mount
           115ms systemd-update-utmp.service
           113ms systemd-journal-flush.service
           111ms triggerhappy.service
            97ms systemd-sysusers.service
            95ms run-rpc_pipefs.mount
            93ms systemd-update-utmp-runlevel.service
            80ms kmod-static-nodes.service
            78ms systemd-random-seed.service
            66ms console-setup.service
            57ms systemd-user-sessions.service
            43ms [e-mail]
            39ms sys-kernel-config.mount
            39ms rc-local.service
            37ms systemd-tmpfiles-setup.service
            36ms nfs-config.service
            30ms boot.mount
            25ms ifupdown-pre.service
            24ms systemd-tmpfiles-setup-dev.service

[Jack V. (jackv)]

Da hast du ja schonmal 12s, die man wegbekommen könnte.

Edit, übersehen:

Marie M. schrieb:
> Wenn ich Spannung anlege, dann sehe ich erst einmal 20s lang nichts

Das sollte in der Tat auch nicht sein – da müsste man aber nähere Infos 
zum verwendeten OS haben, um schauen zu können, woran es liegen mag.

[Johannes S. (Gast)]

Beim Raspi hat doch einen komplexeren Bootmechanismus weil der µC am 
Videoprozessor hängt. Der hat erstmal die Kontrolle, lädt das Image und 
dann darf der ARM werkeln. So vereinfacht aus dem Gedächtnis, hier steht 
mehr dazu:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/bootflow.md

[OS für Hyperaktive (Gast)]

Marie M. schrieb:
> Sind diese langen Zeiten normal?
Ja


> Was macht er da?
Hardware fragen ob sie noch da ist, filesystemchecks, Konfiguration 
erneuern, extended operating System onanism


Kollegen haben mal ein Linux auf unter 2sec boottime gebracht indem sie 
alles rausschmissen was unnötig war. Also Hardware fix konfiguriert 
statt bei jeden boot auszutesten insbesnders nicht den USB-test komplett 
abgeklappert, eigenen reduzierten Kernel ge-built-et, festes 
netzwerk-addresierung, ..

[Jack V. (jackv)]

OS für Hyperaktive schrieb:
> Marie M. schrieb:
>> Sind diese langen Zeiten normal?
> Ja

Nein. Ein Pi3 mit einem plain RaspiOS (früher: Raspbian) sollte in ~15s 
komplett oben sein. Oben ist von über 45s die Rede, und das ist 
definitiv nicht normal.

[Tobias S. (tryan)]

Hallo Marie,

Versuch mal in der /boot/config.txt folgenden Befehl:

hdmi_edid_file=1

auszukommentieren.

Solange kein Display angeschlossen ist.

Viele Grüße Tobias

[Thomas (kosmos)]

PI3B+ Serie 15 Sekunden und mit etwas übertakten des ARM und 
SD-Interfaces hat es um die 12 Sekunden gebraucht.

[Asko B. (dg2brs)]

Bei mir Raspi3B  (ohne +) Startzeit 10 sek.

Thomas O. schrieb:
> PI3B+ Serie 15 Sekunden und mit etwas übertakten des ARM und
> SD-Interfaces hat es um die 12 Sekunden gebraucht.

Wie haste das denn gemacht?
Bei mir ist seit RPi3B und 3B+ das übertakten ausgeschlossen.
System Raspian Stretch vom 26.07.2019

[Thomas (kosmos)]

Das Übertakten über raspi-config mag zwar nicht mehr gehen. Man kann 
aber manuell in der /boot/config.txt  an den Stellschrauben drehen.