LINUXDAY
Fastboot in sistemi embedded
2013
Sommario
•
•
•
•
•
•
•
•
Chi siamo
Cos’è un sistema embedded
Il tempo di boot
Come funziona l’avvio del sistema
Il bootloader
Il kernel
Il filesystem
User space systemd
Linux Day Torino 2013
Chi siamo
Abinsula è un’azienda che propone soluzioni per sistemi
Embedded, nel campo della Sicurezza Informatica e sviluppo di
applicazioni Mobile (Smartphone e Smart TV).
Nata nel marzo 2012 in poco più di un anno conta circa 20 unità
fra dipendenti e collaboratori.
• Paolo Doz
• Skill: sviluppo kernel device driver, customizzazioni
distribuzioni Linux, Linux hacker
• Ilario Pittau
• Skill: sviluppo device driver e hardware test suite,
customizzazioni di sistemi linux embedded
Linux Day Torino 2013
Che cos'è un sistema embedded?
Da Wikipedia…
"In elettronica e informatica, con il termine sistema embedded si identificano
genericamente tutti quei sistemi elettronici di elaborazione a
microprocessore progettati appositamente per una determinata
applicazione spesso con una piattaforma hardware ad hoc, integrati nel
sistema che controllano ed in grado di gestirne tutte o parte delle
funzionalità richieste."
Linux Day Torino 2013
Il tempo di boot
Perché è importante il tempo di boot?
Senza tenere conto di quanto possa essere ben
realizzato un dispositivo, il tempo necessario per
passare dallo stato power off a quello di utilizzo
è un punto critico che può inficiare la userexperience complessiva.
Linux Day Torino 2013
Come funziona l’avvio del sistema
3 sec
4 - 7 sec
Da 10 a 30 o più sec
*
Bloader
Kernel
Init
App 1
App 2
App 3
* Firmware – 10ms
Linux Day Torino 2013
Il bootloader
Da Wikipedia…
Il boot loader è quel programma che, nella fase di avvio (boot) del computer,
carica il kernel del sistema operativo dalla memoria secondaria alla memoria
primaria, permettendone l'esecuzione da parte del processore e il
conseguente avvio del sistema
• Bootloader per sistemi embedded e non:
– Das U-boot (PPC, ARM, x86, MIPS, AVR32, Blackfin, Motorola 68000 e altre
architetture). E’ il più usato nel mondo embedded
– BareBox (PPC, ARM, x86, MIPS, Blackfin). Evoluzione di U-boot, struttura molto
simile al kernel Linux
– GRUB (x86, PowerPc). Utilizzato di default dalla gran parte delle distribuzioni
Linux
Linux Day Torino 2013
Il caricamento del bootloader
• Può essere caricato in RAM ed eseguito oppure
eseguito direttamente dallo storage (XIP)
• Può essere ospitato su differenti tipi di memorie:
– NOR
• Utilizzate nel caso si voglia eseguire del codice direttamente dalla
memoria. Di solito molto piccole ( < 8MB). Veloci in lettura
random, limitati cicli di scrittura, costose.
– NAND
• Scrittura a blocchi gestione via SW. Economiche e più compatte
delle NOR
– eMMC/SD
• Stesse caratteristiche delle NAND ma controllo blocchi via HW.
Facile aggiornare il filesystem di un dispositivo embedded perché
rimovibili
Linux Day Torino 2013
Esecuzione del bootloader
• Il bootloader ha il compito di inizializzare il
sistema
– Clock
– RAM e MMU
– Chip presenti sulla board (es controller audio/video,
tuner, hub usb)
• Mette a disposizione una serie di strumenti molto
utili in fase di sviluppo. Ad esempio avere la
possibilità di utilizzare un filesystem remoto (NFS)
o utilizzare una penna usb per il trasferimento
dati.
Linux Day Torino 2013
Ottimizzazioni
• Rimozione console e autodelay all’avvio
• Rimozione inizializzazioni dispositivi non usati
durante la fase di boot (I2C, FLASH, USB, EXT3,
DOS, FAT, SPI, SATA, VIDEO)
• Rimozione di tutti i comandi non utilizzati
• Dimensione iniziale uboot -> 330KB
• Dopo la rimozione delle funzionalità non
utilizzate -> 93KB (riduzione del 70%)
• Tempo di boot ridotto da 300 ms a 25 ms
Linux Day Torino 2013
Ottimizzare ma non troppo!
Non tutte le inizializzazioni possono essere rimosse, per alcuni
componenti il kernel si aspetta che siano già inizializzati.
Es: ETH del processore Freescale iMX6. Se il chip ethernet non
viene inizializzato in fase di boot, il kernel non riesce a configurare
correttamente il networking
[ 55.004031] ------------[ cut here ]-----------[ 55.009740] WARNING: at net/sched/sch_generic.c:254
dev_watchdog+0x298/0x2b8()
[ 55.018721] NETDEV WATCHDOG: eth0 (fec): transmit queue 0 timed out
Linux Day Torino 2013
Dove è memorizzato il kernel?
Architettura tradizionale
Partition table
Filesystem
/boot/vmlinuz-3.10.0
/boot/vmlinuz-3.11.0
/boot/vmlinuz-3.11.2
Il bootloader legge la
partition table, monta il
filesystem, carica l’immagine
del kernel e poi la esegue
Linux Day Torino 2013
Dove è memorizzato il kernel?
Architettura tradizionale
Architettura ottimizzata
Partition table
Partition table
Filesystem
uImage
Filesystem
/boot/vmlinuz-3.10.0
/boot/vmlinuz-3.11.0
/boot/vmlinuz-3.11.2
Il bootloader legge la
partition table, monta il
filesystem, carica l’immagine
del kernel e poi la esegue
Il bootloader legge dati raw
direttamente dalla memoria
risparmiando il discovery delle
partizioni e il mount del filesystem
bootcmd=mmc read ${loadaddr}
0x800 0x1000 ; bootm
${loadaddr} ;
Linux Day Torino 2013
Caricamento del kernel
• Viene letto dal dispositivo di storage, caricato in
RAM (1), decompresso (2) ed infine eseguito
• Tipi di compressione: LZMA, GZIP, BZIP2, XZ, LZO
Memoria
uImage
(1)
(2)
Storage
Image
uImage
Linux Day Torino 2013
Kernel compresso o no?
TC - Tempo di caricamento
TD - Tempo di decompressione
TC + TD
Gzip
Lzo
Uncompressed
Tempo
Linux Day Torino 2013
Esecuzione
• Lettura della cmdline
• Inizializzazione dell’hw
– Reset e configurazione dei componenti
• Mount del rootfs
– Initrd vs initramfs vs filesystem standard
• Esecuzione del processo init per proseguire il
boot
Linux Day Torino 2013
Ottimizzazione 1/2
• Caricamento e decompressione tramite DMA
• Eliminazione delle virtual console superflue (100ms)
• Skip della calibrazione “loops per jiffy” – lpj – (700ms)
• Finito il tuning del sistema rimuovere le stampe di debug con
"quiet" (200ms)
Linux Day Torino 2013
Ottimizzazione 1/2
• Caricamento e decompressione tramite DMA
• Eliminazione delle virtual console superflue (100ms)
• Skip della calibrazione “loops per jiffy” – lpj – (700ms)
• Finito il tuning del sistema rimuovere le stampe di debug con
"quiet" (200ms)
Esempio di cmdline
console=ttymxc1,115200 vmalloc=40M
consoleblank=0 rootwait root=/dev/mmcblk0p1
lpj=7905280 quiet
Linux Day Torino 2013
Ottimizzazione 2/2
Riduzione della dimensione del kernel:
• Rimozione dei driver inutilizzati o chip/bus non presenti:
bluetooth, wi-fi, pci, flash, scsi, sata, i2c;
• Rimozione del supporto di feature inutilizzate: sysVipc, initrd,
freq-scaler, netfilter, filesystems, debugfs, printk;
• Dove possibile usare driver modulari: ethernet, CAN
Linux Day Torino 2013
Ottimizzazione 2/2
Riduzione della dimensione del kernel:
• Rimozione dei driver inutilizzati o chip/bus non presenti:
bluetooth, wi-fi, pci, flash, scsi, sata, i2c;
• Rimozione del supporto di feature inutilizzate: sysVipc, initrd,
freq-scaler, netfilter, filesystems, debugfs, printk;
• Dove possibile usare driver modulari: ethernet, CAN
Kernel iniziale
3.6 MB
Kernel ottim.
1.6 MB
280
160 20
50
4141
Tempo di caricamento in ms
941
Tempo di decompressione in ms
Tempo di esecuzione in ms
Linux Day Torino 2013
Kernel e filesystem
L’immagine del kernel (uImage) può essere composta da:
• Solo kernel
• Pro: file molto piccolo, veloce da caricare
• Contro: il mount del filesystem finale rallenta un po’ il boot
• Kernel + initrd
• Pro: è molto veloce montare il filesystem in RAM
• Contro: richiede un driver per la lettura del filesystem (es ext2), per
questo è stato rimpiazzato da initramfs
• Kernel + initramfs
• Pro: usa tmpfs, riconosciuto automaticamente dal kernel, molto
utilizzato nei sistemi embedded.
• Contro: complicato effettuare lo switch root alla fine della fase di boot
per montare il filesystem finale
Linux Day Torino 2013
Filesystem 1/2
Come districarsi nella giungla dei filesystem embedded?
Esistono tanti filesystem adatti per sistemi embedded, ognuno con
caratteristiche diverse per ogni utilizzo:
- Ext2, Ext3
• Adatti ad ogni storage, molto robusti e supportati.
- ReiserFS, Ext4
• Non particolarmente veloci a causa del journaling, inadatti per sistemi
embedded.
- Jffs2, UbiFS, SquashFS, F2FS
• Adatti a memorie flash e/o partizioni read-only
Linux Day Torino 2013
Filesystem 2/2
Differenza di mount su MMC con diversi Ext filesystem:
ext2
Startup finished in 991ms (kernel) + 2.592s (userspace) = 3.584s
ext3
Startup finished in 941ms (kernel) + 2.553s (userspace) = 3.494s
ext4
Startup finished in 1.125s (kernel) + 2.639s (userspace) = 3.765s
Linux Day Torino 2013
systemd 1/2
Dal sito di systemd :
systemd è un sistema e gestore dei servizi per Linux, compatibile con gli init
scripts SysV e LSB. systemd permette una parallellizzazione aggressiva dei task,
usa socket e D-Bus per far partire i servizi, permette di far partire i demoni ondemand, tiene traccia dei processi usando i Linux cgroups, supporta lo
snapshotting e il restoring dello stato del sistema, mantiene i mount e
automount point e implementa una elaborata logica di controllo dei servizi.
Mira a diventare un sostituto per sysVinit.
Linux Day Torino 2013
Confronto gestori di init
Syslog
D-Bus
Avahi
Bluetooth
Traditional SysV
Linux Day Torino 2013
Confronto gestori di init
Syslog
Syslog
D-Bus
D-Bus
Avahi
Avahi + Bluetooth
Bluetooth
Traditional SysV
Suse/Debian parallelization
Linux Day Torino 2013
Confronto gestori di init
Syslog
Syslog
D-Bus
D-Bus
Avahi
Syslog + D-Bus
+ Avahi+
Bluetooth
Avahi + Bluetooth
Bluetooth
Traditional SysV
Suse/Debian parallelization
Linux Day Torino 2013
systemd
systemd 2/2
Il funzionamento base
Il processo systemd avviato come primo processo legge la cmdline per capire il
target da raggiungere e accede a "/lib/systemd/system/" per leggere i file di
configurazione:
- systemd.target: sono punti statici da raggiungere durante il boot.
- systemd.[auto]mount: rappresentano i dispositivi che devono essere
montati, possono essere montati anche su richiesta.
- systemd.service: rappresentano i servizi, normalmente chiamano un demone
o un generico applicativo.
- systemd.socket: implementano i socket su cui systemd bufferizza o ascolta le
richieste per avviare i .service.
Linux Day Torino 2013
Service di systemd
Esempio del service relativo a syslog
[Unit]
Description=System Logging Service
Wants=busybox-klogd.service
[Service]
EnvironmentFile=-/etc/default/busybox-syslog
ExecStart=/sbin/syslogd -n $OPTIONS
Sockets=syslog.socket
[Install]
WantedBy=multi-user.target
Also=busybox-klogd.service
Alias=syslog.service
Linux Day Torino 2013
Linux Day Torino 2013
Linux Day Torino 2013
Ottimizzazioni 1/2
Come fare il debug dello startup?
#
#
#
#
systemd-analyze plot
systemd-analyze critical-chain
systemctl [start/stop/status] <nomeservice>
journalctl
Quali servizi ci servono?
- Rimozione di NFC(1s), Ofono (1s), Avahi(800ms), alsa-restore(200ms), video
(700ms).
- Rimangono getty, d-bus, applicazione audio
Linux Day Torino 2013
Ottimizzazioni 2/2
Che configurazioni statiche si possono fare?
• Creazione statica delle cartelle/file/dev temporanei. (529ms)
• Linkare le cartelle temporanee il più possibile per montare pochi tmpfs
(600ms)
• Rimozione dei postinits (supporto ai vecchi script SysV) (170ms)
• Mount con fstab, Random-seed (1s)
• Modalità single-user o rimozione dei blocchi al login (3s)
Cosa si deve montare?
• proc e sysfs: viene fatto automaticamente da systemd
• tmpfs: /var/volatile /run
• devpts, debugfs: possono essere disabilitati (1.2s)
Linux Day Torino 2013
Risultati
25 ms
0.9 sec
2.5 sec
*
U-boot
Kernel
Systemd
App 1
App 2
App 3
* Firmware – 10ms
Linux Day Torino 2013
Conclusioni
• Si può migliorare ancora?
Linux Day Torino 2013
Conclusioni
• Si può migliorare ancora?
– Ovviamente si
• Creazione dei device e rimozione di udev
• Modifiche nel codice sorgente
• Sistema di init basato su script custom
Linux Day Torino 2013
Conclusioni
• Si può migliorare ancora?
– Ovviamente si
• Creazione dei device e rimozione di udev
• Modifiche nel codice sorgente
• Sistema di init basato su script custom
• Conviene?
Linux Day Torino 2013
Conclusioni
• Si può migliorare ancora?
– Ovviamente si
• Creazione dei device e rimozione di udev
• Modifiche nel codice sorgente
• Sistema di init basato su script custom
• Conviene?
– Dipende
• Tempi
• Costi
Linux Day Torino 2013
Demo
• Solo teoria?
• Board Freescale iMx 6, SD e fs creato con
Ability
Linux Day Torino 2013
Ability
Ability è una meta-distribuzione creata da Abinsula. E’ basata su Open
Embedded ed è fortemente orientata al mondo dei dispositivi embedded.
Tempi di boot ridotti
Efficienza del power
management
Supporto device
mobile
Affidabilità
GENIVI compliant
Linux Day Torino 2013
Grazie….
http://www.abinsula.com
[email protected] [email protected]
Linux Day Torino 2013