Buildroot 4 anni dopo ma sempre su Arietta G25.

Parte seconda. I files defonfig.

Vorrei iniziare questo secondo breve articolo facendo un poco il punto su nomi e comandi.

Chiariamo una volta per tutte che Buildroot è un tool che automatizza il processo di creazione di quella che potremmo definire una sorta di “distribuzione” personalizzatissima, snella ed efficiente, per il nostro sistema embedded.
Il tool affronta tutti gli aspetti di questo processo ed è in grado di generare una immagine del kernel, un bootloader ed un root file system utilizzando un cross compilatore che può essere generato da Buildroot stesso, come nel nostro caso, od importato dall’esterno.

Come visto nella prima parte, all’interno della directory ./configs troviamo una buona quantità di files di configurazione (+ di 200 nella versione in uso).
Il nome di detti files finisce per defconfig ed è preceduto dal nome del costruttore e/o modello del sistema embedded cui si riferisce.
Ad esempio: atmel_sama5d27_som1_ek_mmc_dev_defconfig oppure arcturus_ucls1012a_defconfig e così via.

Lo scopo di detto file è quello di effettuare una prima grossolana configurazione fornendo informazioni basilari come il tipo di processore, informazioni sul Kernel, oltre ai percorsi dove ci aspetteremo di trovare ciò che ci serve.

Va però precisato che i defconfigs contengono solo le opzioni diverse da quelle di default.
Chiunque può creare un suo defconfig con il comando:

$ make savedefconfig

In questo modo nel file appena creato esisteranno solo le opzioni di configurazione differenti da quelle di default.
In pratica avremo salvato soltanto le modifiche effettuate in fase di configurazione.
A questo punto sarà utile spostare e rinominare il file defconfig nella directory ./config/mio_defconfig:

mv defconfig configs/mio_defconfig

L’insieme di tutte le informazioni per la generazione della build sono invece contenute nel file .config che si trova nella topdir di buildroot.
Si segnala anche la presenza del .config.old in cui viene copiato il contenuto del .config ad ogni salvataggio della configurazione.
Attenzione! Salvare 2 volte mentre si sta configurando il sistema ad esempio con make menuconfig significa rendere identici i due files e di fatto perdere la configurazione precedente.

Che si tratti di un defconfig preconfigurato o di uno creato da noi, per far si che alla configurazione di default (.config) vengano applicate le opportune modifiche useremo il comando:

$ make acmesystems_arietta_g25_128mb_defconfig

nel caso del file che abbiamo visto essere già fornito nel pacchetto, oppure il comando

$ make mio_defconfig

nel caso si tratti di un file generato da noi.

Da questo momento il path del defconfig in uso verrà aggiornato nel file .config.
Di fatto:

$ more .config | grep BR2_DEFCONFIG=
BR2_DEFCONFIG="/home/antonino/sviluppo/provabuils/buildroot-2016.02/configs/mio_defconfig"

Se per primo ci fossimo avvalsi del defconfig già fornito nella distribuzione di buildroot l’output del precedente comando sarebbe stato:

$ more .config | grep BR2_DEFCONFIG=
BR2_DEFCONFIG="/home/antonino/sviluppo/provabuils/buildroot-2016.02/configs/acmesystems_arietta_g25_128mb_defconfig"

Qualunque successivo make savedefconfig andrebbe a scrivere sul percorso pocanzi evidenziato.
N.B. questo vale solo nell’ambiente Buildroot. Un make savedefconfig compilando un kernel in maniera tradizionale continua a creare un file defconfig nella top dir di linux.
Inutile precisare che se questo nome dovesse proprio esserci antipatico potremo rinominarlo:

$ mv configs/acmesystems_arietta_g25_128mb_defconfig configs/nome_rinominato_defconfig

e dopo un:

$ make nome_rinominato_defconfig

ecco che:

nel file .config avremo nuovamente il path aggiornato:

$ more .config | grep BR2_DEFCONFIG=
BR2_DEFCONFIG="/home/antonino/sviluppo/provabuils/buildroot-2016.02/configs/nome_rinominato_defconfig"

 

Forse mi sono dilungato anche troppo, ma desideravo che l’uso dei files defconfig fosse chiaro.
Sopratutto a me stesso.

 

 

Pubblicato in Digitale, Linux.

admin

Admin, per l'anagrafe Antonino Brisindi e per i colleghi radioamatori IZ0HEM,
nasce a Giugno del 1972.
Si cimenta in diverse discipline. Dal motociclismo all'elettronica.
Dalla meccanica delle chiavi inglesi al Jazz delle ance.
Dalla cucina dei fornelli alle dinamiche di volo ad ala mobile.
Interagisce con tutto quello che intercorre tra un 6502 ed un sistema embedded.
Capisce davvero poco di tutto quello che fa ed in questo periodo ama definirsi un pessimo system integrator! ;-)