Home
Accesso / Registrazione

arighi

ritratto di arighi

User title

User

PROFILO

Profilo Google+

Google+

Cronologia

Membro da
1 anno 50 settimane
Blog
Vedi messaggi recenti del blog

 

 

Ultimi POST

ritratto di arighi

Riservato agli Abbonati PLATINUMOttimizzare i tempi di Boot sulla Raspberry Pi

Embedded PC Linux & Windows
ritratto di arighi

Riservato agli Abbonati PLATINUMEmbedded GNU/Linux partendo da zero: test sulla Raspberry Pi

Linux
ritratto di arighi

Riservato agli Abbonati PLATINUMEmbedded GNU/Linux partendo da zero: integrazione e test

Linux

Ultimi Commenti

Per fare porting di Linux su un'architettura "nuova" (immagino si riferisca a questo la domanda) e` necessario scrivere un layer di compatibilita` che andra` poi collocato sotto arch/arm/. Se hai i sorgenti di un kernel recente alla mano puoi provare a listare la directory arch/arm per avere un'idea delle varie architetture ARM correntemente suportate: $ ls arch/arm/ boot mach-ebsa110 mach-mv78xx0 mach-s5pc100 Makefile common mach-ep93xx mach-mvebu mach-s5pv210 mm configs mach-exynos mach-mxs mach-sa1100 net crypto mach-footbridge mach-netx mach-shark nwfpe include mach-gemini mach-nomadik mach-shmobile oprofile Kconfig mach-highbank mach-nspire mach-socfpga plat-iop Kconfig.debug mach-imx mach-omap1 mach-spear plat-omap Kconfig-nommu mach-integrator mach-omap2 mach-sti plat-orion kernel mach-iop13xx mach-orion5x mach-...
Ciao Ivan, scusami per la risposta in ritardo. Allora, se ti interessa capire come costruire una board che supporti Linux mi viene difficile darti consigli, perche` non ho esperienza in merito. Io ho sempre lavorato su hardware gia` fatto, sono un softwarista / kernel-ista puro. Al limite mi limito a dire "questo hardware non va, fa schifo, rifatelo". :) Per il discorso porting Linux, qualora ti interessase imparare come fare, io a scopo didattico ti consiglieri di partire da una board esistente che ha gia` un supporto Linux completo, es. una RaspberryPi o una BeagleBoard. Partendo da un'architettura del genere proverei ad esempio a riscrivere un driver di un dispositivo semplice, un RTC, un driver per controllare dei semplici pin di GPIO, anche accendere e spengere un LED via procfs o sysfs, roba del genere insomma. Se qualcosa non funziona o non sai come fare puoi consultare il driver originale se c'e`, oppure puoi consultare un driver che fa qualcosa di simile, se ti servono delle...
Grazie, mi fa piacere che l'articolo ti abbia incuriosito. Allora, pasticci troppo grossi sulla RPi in genere non se ne dovrebbero fare... al limite basta ri-flashare l'SD card per tornare ad uno stato funzionante. :) Ad ogni modo sentiti libero di contattarmi mandando un messaggio o postando un commento qua sotto se hai bisogno di aiuto o riscontri errori, problemi, etc. nel seguire i passaggi riportati sopra.
Esatto, ottima domanda, grazie! In effetti me l'aveva fatto notare anche Piero Boccadoro. Il fatto e` che qua ho saltato un bel po' di passaggi e l'espressione non e` un'uguaglianza ma il risultato di un'approssimazione. Vediamo di chiarire. Ovviamente con CONFIG_HZ=100 la singla attesa di un tick richiede 1 / 100 s = 10 ms. Tuttavia il kernel per fare una valutazione piu` precisa del numero di loop che la CPU riesce a fare in un jiffy, reitera l'attesa piu` volte nella funzione calibrate_delay(), effettuando una prima fase di calibrazione e successivamente una fase di approssimazione binaria, fino a che non si converge ad un valore sufficientemente attendibile. Di tali attese da 10ms se ne possono fare fino ad un massimo di 27, per cui la calibrazione potrebbe richiedere fino a 270 ms, quindi in prima approssimazione l'attesa e` dell'ordine di 250ms. I dettagli della procedura si possono trovare nella patch che ha introdotto il parametro di boot lpj, utilizzato per fare il preset dei...
Grazie degli apprezzamenti. ;) Per il discorso di alleggerire la Raspian, beh.. dipende da quali sono le esigenze. In generale l'esigenza tipicamente richiesta in ambito embedded e` di alleggerire una distro per velocizzare i tempi di boot. A volte basta banalmente dare un'occhiata ai servizi che vengono avviati al boot in /etc/init.d/ (es. puo` essere fatto partire il server X anche quando si usa la board esclusivamente da remoto via ssh, o cose del genere). Un altro cambiamento che sarebbe interessante testare e` di utilizzare un altro filesystem per il rootfs. Raspbian usa ext4, un filesystem solido e affidabile, ma l'overhead del journal in certi casi potrebbe essere evitato. Es. alcune board adottano CRAMFS per il root filesystem (un filesystem read-only) + dati modificabili (/home, /etc, /var/log, etc.) su tmpfs (un filesystem in RAM), o ext2. Sicuramente questa sarebbe una soluzione piu` leggera e performante rispetto ad avere tutto su ext4. Ultimo aspetto, che tra l'altro e`...
Login   
 Twitter Facebook LinkedIn Youtube Google RSS

Chi è online

Ultimi Commenti