Boot Linuxu do 1 sekundy: Splněno

Embedded Bits ukazuje video, které předvádí boot linuxového jádra za méně než 1 sekundu. Jde o projekt swiftBoot firmy MPC Data. Použitý hardware: ARM cortex-a8 na 500MHz vývojové desce Texas Instruments OMAP3530 EVM. Jádro 2.6.29 a souborový systém pro flash NAND. Zařízení po bootu spustí aplikaci na zachytávání videa z kamery a toto video zobrazí na LCD. To vše za méně než sekundu.

1.3.2010 10:52 | Robert Krátký | Zajímavý projekt

Komentáře

[Mythical playboy]

On to skutočný boot nebude, len sa prebere zo spánku, v romke sú už načítané drivery a ..., aspoň myslím že to tak bude, to ma kedysi napadlo, ale nezrealizoval som to

[ZS-Man]

No na tom videu je videt jak odpoji a pripoji napajeni. Takze by se to dalo povazovat za skutecny boot.

[Mythical playboy]

Je to taký boot, bez bootu

[ewqrqwr]

asi bude rozdil mezi bootem plnohodnotneho pc s milionem ruznych soucasti hw a bootem "jednoucelove" desky s minimalistickym jadrem, minimem hw a startujici z flash disku.

[Ctirad Feřtr]

Ani ne.

[petr_p]

Asi tak. Mně taky Linux bootuje (od zavaděče do spuštění initu) do několika (asi tak 3) sekund. Nejdéle trvá připojení souborového systému. Prostě staré PC, kde je téměř vše napevno připojeno a zakompilováno do jádra.

Zbytek (init) je pouze otázka obecnosti startovacích skriptů. Když jsem si psal vlastní skripty (síť, ssh, iptables, alsa, hwclock, připojení další souborových systémů), tak jsem měl login za dalších 7 sekund.

Teď používám openrc a čas se natáhl asi o dalších 10 sekund. Jenže to mi je stejně jedno, protože uprostřed se systém zastaví, protože chce heslo na rozšifrování LVM.

[R]

Nacitane drivery v ROMke? To je co za nezmysel? Radsej nekomentuj, ked o tom nic nevies.

[Mythical playboy]

Takže tá moja teória, RAM a ROM sa správajú ako jedna pamäť, nabutuješ Linux do RAM, procesy ktoré nemenne bežia čo je väčšina systému aj s drivermi "napáliš" do ROM, pri ďalšom zapnutí sa len najnutnejšia časť presune s ROM do RAM a spustí sa "spiaci" Linux, niečo ako hybernácia, ale ďaleko rýchlejšie, nič nedokáže nabootovať za menej ako sekundu, ani jednoúčelový MSDOS, môj Android bootuje tak isto rýchlo ako stolné PC cca pol minútu, nestopoval som to.

[R]

Skompiluj si (na tom desktope) jadro bez initramfs a daj si ako parameter init=/bin/sh. A uvidis, ze aj na x86 sa jadro spusti velmi rychlo.

[Jiří J.]

Moje odlehčené livecd (jen kernel + komprimovaný initramfs) mi na stolním PC (x86) bootuje do shellu (přes busybox init skripty, mount squashfs, ...) za ~460 milisekund. Včetně dekomprese initramfs. Boot počítám od spuštění kódu kernelu.

[Mythical playboy]

Tak ono do nepoužitelnej podoby to nabootuje rychlo
Pochybujem ale že by si tam dokázal zobraziť obraz z webky.

[Jiří J.]

No on by ten framebuffer zas tolik času navíc nepřidal

[Ctirad Feřtr]

Určitě je to 460ms (necelá půlvteřina) od spuštění jádra po shell? To by byl světový rekord, na který se nehrabe ani uvedené video ;)

[petr_p]

Proč by ne? Když je rootfs v initramfs, tak v podstatě všechno načte do paměti zavaděč. Když nemusíte prohledávat některé sběrnice (SCSI, USB) a inicializovat pomalý hardware, tak jádro samo o sobě plus statický busyboxový shell neběhne opravdu rychle. V qemu jsem takových bootů viděl nepočítaně.

[Ctirad Feřtr]

Vzhledem k tomu, že sestavování právě takovýchto minimalistických embedded systémů patří posledních pár let k podstatné části mojí pracovní náplně, troufám si tvrdit, že mám určitý přehled o tom, co se mi jak dlouho spuští. A za 0,46s se mi opravdu ani nezinicializuje jádro do té míry, aby začalo vůbec přemýšlet o tom, co má spustit jako init, byť by to byl jenom ash z busyboxu zabaleného v initramfs přímo do binárky jádra. Jako reálnější vidím spíš ~5s, což je hodnota řádově vyšší.

[petr_p]

Pak je ale problém v architektuře (případně jejích ovladačích v jádře). Já s vestavěnými systémy mám malé zkušenosti, ale co jsem si všiml, tak problém byl spíš v inicializaci daného hardwaru (pomalé prohledávání mtd, samé čekání na timeouty a především zpomalený výstup přes sériovou konzolu).

Nezpochybňuji, že na vestavěných systémech to je úspěch. Pouze ukazuji, že obecně to žádný rekord není, protože existují stroje, kde takové časy lze vykouzlit.

(Nasadil jste mi brouka do hlavy, a asi si to budu muset změřit.)

[Ctirad Feřtr]

Architekturou to není. Je to v podstatě stejné na čekomkoliv. Uvědomte si, jak krátký okamžik půl sekundy je. V podstatě by jenom bliknula obrazovka a už by najížděl init, což je opravdu nereálné.

[Jiří J.]

Dovoluji si vám oznámit, že hardware onoho testovaného stroje má zásadně více, než 500MHz a že kernel sám o sobě má kolem 200-300KB (gzip) místo obvyklých 1.5+MB. Není tam prakticky nic, co by muselo, není tam podpora pro MD, žádné extra video drivery, network drivery, není tam prakticky skoro vůbec nic.

S dobou bootu jsem se asi trochu sekl, počítám to od doby, kdy kernel začne vypisovat první printk(), do té doby těžko odlišit, co je ještě kód bootloaderu a co už kernel. Boot je skutečně "jen" probliknutím, než se spustí shell. Upozorňuji, že je vše v paměti (initramfs) a kernel při startu inicializuje leda tak paměť, video drivery a PS/2 keyboard. Podpora pro PCI, USB, jakýkoli storage (IDE, SATA, ..), filesystémů (včetně tmpfs, root jede z ramfs) a spoustu dalších věcí chybí.

[Jendа]

OT: k čemu je taková bez ničeho dobrá?

[Jendа]

Chybí tam slovo „distribuce“…

[Jiří J.]

K tomu, abych dokázal Ctiradovi, že Linux umí bootovat za méně, než 5 sekund

Upřímně jsem takový systém doopravdy měl, postupně ta podpora samozřejmě přibyla, stejně tak komprimované /lib/modules se všemi drivery pro disky a síťové karty, oháčkovaný busybox, portmap, NFS (včetně utility na export) a mke2fs - vše s uClibc (u pár věcí jsem musel přepisovat GNUismy a obsolete věci v kódu.

V současné době je to ~6MB userspace a ~600KB kernel a slouží jako odlehčený PXE server s podporou NFS a pár celkem unikátními vlastnostmi ("kooperace" s jiným autoritativním DHCP serverem na síti - užitečné při hromadném bootu něčeho, co si má natáhnout kernel+initrd z PXE serveru, ale co se má po nabootování připojit do klasické sítě s krabičkovým routerem). Userspace po dekompresi má okolo 7MB (díky squashfs /lib/modules a /usr/bin), nicméně do 8MB RAM u (hodně) starých mašin se to asi nevleze díky dekomprimovanému kernelu. Ještě bych mohl memtest86+ ("proof-of-concept" a default v pxelinux.cfg) zkomprimovat, ale 160KB -> 90KB zas toliko není

Tvořil jsem to víceméně ve volném čase, v současné chvíli je to asi půl roku v zapomnění, mám v plánu se k tomu někdy vrátit, dodělat TeX dokumentaci, sjednotit nějak "SDK" a build procedury (v současnosti 2 qemu systémy a busybox+buildroot s configy na dalším linux serveru), NFS write locking, apod.

[Jiří J.]

Jen tak pro zajímavost - našel jsem někde v koši fragment toho, co jsem používal jako "poznámkový blok" pro kompilaci 3rd-party věcí:

export PATH="/usr/src/buildroot/build_i486/staging_dir/usr/bin/:$PATH"


nfs-tools:
./configure \
  --target=i486-linux \
  --host=i486-linux \
  --build=i486-pc-linux-gnu \
  --disable-nfsv4 \
  --disable-gss \
  --disable-tirpc \
  --disable-uuid \
  --disable-mountconfig \
  --without-tcp-wrappers \
  CFLAGS="-march=i486 -Os -pipe -fomit-frame-pointer"
make


portmap:
CFLAGS="-march=i486 -Os -pipe -fomit-frame-pointer" \
make CC="i486-linux-gcc" NO_TCP_WRAPPER=yes DAEMON_UID=0 DAEMON_GID=0


e2fsprogs:
./configure \
  --target=i486-linux \
  --host=i486-linux \
  --build=i486-pc-linux-gnu \
  --enable-verbose-makecmds \
  --disable-compression \
  --disable-htree \
  --disable-elf-shlibs \
  --disable-bsd-shlibs \
  --disable-profile \
  --disable-checker \
  --disable-jbd-debug \
  --disable-blkid-debug \
  --disable-testio-debug \
  --disable-debugfs \
  --disable-imager \
  --disable-resizer \
  --disable-fsck \
  --disable-e2initrd-helper \
  --disable-tls \
  --disable-uuidd \
  --disable-nls \
  --disable-rpath \
  CFLAGS="-march=i486 -Os -pipe -fomit-frame-pointer"
make

Ten mke2fs tam je vesměs jen kvůli NFS, ramfs/tmpfs mi nešel exportovat ani přes vygooglené triky (přes fsid).

Ale dost OT