compilare kernel

78 views
Skip to first unread message

nicola_bbC4

unread,
Oct 13, 2012, 12:34:36 PM10/13/12
to bb_pr...@googlegroups.com
Salve a tutti e ringrazio in anticipo.

Sto svolgendo uno studio sul kernel, e ho la necessità di inserire dei printk di kernel-info.
Una volta scaricato il kernel e modificato, seguo questa wiki http://elinux.org/BeagleBoard#Linux_kernel per compilarlo e poi farlo girare nella beagleboard ma mi da questo errore:

nicola@nicola-U-100:~/linux-omap$ make ARCH=arm uImage
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
make[1]: "include/generated/mach-types.h" è aggiornato.
  CC      kernel/bounds.s
cc1: error: unrecognized command line option ‘-mlittle-endian’
cc1: error: unrecognized command line option ‘-mno-thumb-interwork’
kernel/bounds.c:1:0: error: unknown ABI (aapcs-linux) for -mabi= switch
kernel/bounds.c:1:0: error: bad value (armv5t) for -march= switch
kernel/bounds.c:1:0: error: bad value (strongarm) for -mtune= switch
make[1]: *** [kernel/bounds.s] Errore 1
make: *** [prepare0] Errore 2

qualcuno ha qualche suggerimento per uscire da questo impiccio...
Grazie a chiunque mi possa aiutare.
nicola.

Mauro Gamba

unread,
Oct 18, 2012, 2:52:31 AM10/18/12
to bb_pr...@googlegroups.com
Ciao,
devi settare anche il cross-compilatore settando la variabile CROSS_COMPILE.

nicola_bbC4

unread,
Oct 19, 2012, 3:59:16 PM10/19/12
to bb_pr...@googlegroups.com
Ciao Mauro,

grazie mille dell'informazione, ho provato seguendo il link che mi hai segnalato, e mi ha effettuato la compilazione senza errori.... Purtroppo mi è sorto un altro problema,nel tentativo di usare l'uImage appena ricompilato.
Inizialmente avevo ubuntu 12.04 nella beagleboard, e dato che non funzionava la uImage, ho pensato "BENE" di installare Angstrom.... dopo svariati fallimenti, ho usato questi comandi per cancellare la nand

mmcinit
mmc init
mmc rescan 0
fatload mmc 0 82000000 MLO
nand unlock
nand ecc hw
nandecc hw
nand erase 0 80000
nand write 82000000 0 20000
nand write 82000000 20000 20000
nand write 82000000 40000 20000
nand write 82000000 60000 20000
fatload mmc 0 0x80200000 u-boot.img
nand unlock
nand ecc sw
nandecc sw
nand erase 80000 170000
nand write 0x80200000 80000 170000

ho riavviato, e ora nel terminale di minicom mi esce una sfilza di:

Error: Bad compare! failed 

sia con la che senza SDcard.

sto impazzendo nel cercare cosa ho combinato!!!
se hai qualche consiglio ne sarei molto grato, e ringrazio chiunque possa aiutarmi.

nicola_bbC4

unread,
Oct 23, 2012, 11:24:57 AM10/23/12
to BeagleBoard Projects
ciao a tutti.
Per chiunque ne avesse bisogno ho risolto il problema precedentemente
descritto, semplicemente costruendo una sdcard di recupero seguendo
questo:

http://elinux.org/BeagleBoardUbuntu#Upgrade_X-loader_and_U-boot

Salvato in nand l'u-boot della sdcard di recupero, creo una sdcard con
dual-partition con angstrom o ubuntu (funziona egualmente) seguendo
questo sito consiglio:

http://downloads.angstrom-distribution.org/demo/beagleboard/

PS:
il comando:

fatload mmc 0 0x80200000 u-boot.img

mi dava problemi ma usando u-boot.bin è andato tutto ok.

Il MLO e u-boot.bin lo ho scaricato da

http://code.google.com/p/beagleboard/wiki/BeagleNANDFlashing

mentre il file uImage si trova nella cartella /media/Angstrom/boot
della partizione ext3 della sdcard.
Questo va rinominato e copiato nella partizione fat chiamata boot
della sdcard.
Spero sia abbastanza chiaro...
> >>http://elinux.org/BeagleBoard#Linux_kernelper compilarlo e poi farlo

Stefano Tim

unread,
Oct 24, 2012, 12:55:27 AM10/24/12
to bb_pr...@googlegroups.com
Montelupo Fiorentino, 24 Ottobre 2012

Buongiorno a tutti,

io sto facendo delle prove con una beagle board xM con la distro che
preinstallano sull'SD (micro) del pacchetto. Ho installato dal sito di JAMES
l'mpd player Ver.0.15.2 e sto facendo delle misure con l'oscillo per vedere
i segnali I2S che sono riportati a connettore come si muovono per poterci
poi attaccare un DAC.
Per il momento non sono riuscito mai a vedere frequenze superiori a 1,411
MHz che equivalgono a un rate di 44100 per 16 bit per 2 canali. Ho provato
ovviamente a dargli in pasto file .FLAC a 24 bit ed ho provato anche Rytmbox
ed mplayer ma non riesco a forzare le frequenze superiori anche passando le
varie opzioni che prevedono i parametri tipo audio_buffer_format 44100:16:2
sostituirlo con 44100:24:2 non ha efficacia.
Anche con mplayer forzandogli demux rawaudio -rawaudio e le varie opzioni
che seguono per i suddetti parametri mi risulta che a video vengono
acquisiti i parametri da me impostati ma sull'oscillo vedo sempre la stessa
frequenza.

Qualcuno mi sa dare una mano ? Oppure mi pu� indicare a chi potrei rivolgere
questa domanda ?

Grazie comunque dell'interesse.

Saluti Stefano Pria

Alfonso Martone

unread,
Oct 24, 2012, 9:01:12 AM10/24/12
to bb_pr...@googlegroups.com
Ciao,

la Beagleboard ha alcuni limiti sull'hardware, scelti per economia di
esercizio. Per esempio sui pin GPIO la massima frequenza di
campionamento � 4 milioni di sample al secondo (cio� il "cap" � di
4MHz). Poi, la "scheda audio" � in realt� una "feature" del chip
regolatore di tensione (ossia ti fa solo i 44KHz stereo, non ha
frequenze programmabili).

Tutti i software audio (incluso mplayer) sono costretti a fidarsi di ci�
che gli d� il kernel (cio� i 44.1KHz), non possono fare miracoli.

Qualcuno pi� ferrato ha usato l'interfaccia McBSPI per trasferire dati
audio , qualcun altro ancora pi� fanatico ha usato i pin della MMC2, ma
non saprei dirti altro che spazzolarti bene il googlegroup ufficiale
della beagleboard e la pagina della beagleboard (non troppo aggiornata,
per la verit�) su elinux.org.

Ricordo a tutti che la distribuzione col kernel pi� avanzato � la
Angstrom Linux (quella fornita di serie con la Beagleboard xM), da
aggiornare coi comandi "opkg update; opkg upgrade"; attualmente sto
usando la Arch Linux ARM ma ho dovuto metterci il kernel della Angstrom
(moduli inclusi) perch� altrimenti non mi vedeva il debugfs e altre cose
relative ai GPIO.
> Qualcuno mi sa dare una mano ? Oppure mi pu� indicare a chi potrei

Stefano Pria - Tim

unread,
Oct 31, 2012, 3:28:38 AM10/31/12
to bb_pr...@googlegroups.com
Montelupo Fiorentino, 31 Ottobre 2012

Grazie a tutti dell'attenzione,
in particolar modo mi rivolgo a Alfonso Martone che mi ha risposto a tempo di record.... la mia ulteriore perplessità è questa: mi piacerebbe capire il flusso logico dei dati audio:
mplayer o mpd leggono il file musicale secondo il formato con cui sono memorizzati su disco e lo trasformano in uno streaming da passare al driver ALSA (piuttosto che OSS) e questo a sua volta lo prende in formato "standard" e lo passa al modulo audio che conosce l'hardware che è compilato nel kernel ?
Ho detto un sacco di ...zate o più o meno questo è il flusso logico ?
Nel caso in cui volessi provare a settare i registri del chip OMAP (che mi sembra quello che svolge il mestiere di generare i segnali che interessano a me per andare a pilotare il DAC) dovrei recuperare i sorgenti della distribuzione che ho sulla micro SD, installare l'ambiente per ricompilarli, trovare i punti dove vengono programmati i registri e una volta modificati rigenerare il tutto con i nuovi valori e vedere se il risultato cambia..... 
Se cosi fosse c'è qualcuno che mi può dare qualche suggerimento (non chiedo un tutorial sarebbe troppo bello anche se credo che qualcuno abbia già percorso una strada analoga magari per altri obiettivi) per non perdermi nell'universo WEB e riuscire ad essere operativo velocemente sia per la rigenerazione dell'immagine, sia nel trovare i file da toccare.

Grazie ancora a tutti coloro che mi daranno un aiuto......

Saluti
Stefano Pria

Il giorno 24 ottobre 2012 15:01, Alfonso Martone <alfonso...@gmail.com> ha scritto:
Ciao,

la Beagleboard ha alcuni limiti sull'hardware, scelti per economia di esercizio. Per esempio sui pin GPIO la massima frequenza di campionamento è 4 milioni di sample al secondo (cioè il "cap" è di 4MHz). Poi, la "scheda audio" è in realtà una "feature" del chip regolatore di tensione (ossia ti fa solo i 44KHz stereo, non ha frequenze programmabili).

Tutti i software audio (incluso mplayer) sono costretti a fidarsi di ciò che gli dà il kernel (cioè i 44.1KHz), non possono fare miracoli.

Qualcuno più ferrato ha usato l'interfaccia McBSPI per trasferire dati audio , qualcun altro ancora più fanatico ha usato i pin della MMC2, ma non saprei dirti altro che spazzolarti bene il googlegroup ufficiale della beagleboard e la pagina della beagleboard (non troppo aggiornata, per la verità) su elinux.org.

Ricordo a tutti che la distribuzione col kernel più avanzato è la Angstrom Linux (quella fornita di serie con la Beagleboard xM), da aggiornare coi comandi "opkg update; opkg upgrade"; attualmente sto usando la Arch Linux ARM ma ho dovuto metterci il kernel della Angstrom (moduli inclusi) perché altrimenti non mi vedeva il debugfs e altre cose relative ai GPIO.




On 24/10/12 06:55, Stefano Tim wrote:
Montelupo Fiorentino, 24 Ottobre 2012

Buongiorno a tutti,

io sto facendo delle prove con una beagle board xM con la distro che preinstallano sull'SD (micro) del pacchetto. Ho installato dal sito di JAMES l'mpd player Ver.0.15.2 e sto facendo delle misure con l'oscillo per vedere i segnali I2S che sono riportati a connettore come si muovono per poterci poi attaccare un DAC.
Per il momento non sono riuscito mai a vedere frequenze superiori a 1,411 MHz che equivalgono a un rate di 44100 per 16 bit per 2 canali. Ho provato ovviamente a dargli in pasto file .FLAC a 24 bit ed ho provato anche Rytmbox ed mplayer ma non riesco a forzare le frequenze superiori anche passando le varie opzioni che prevedono i parametri tipo audio_buffer_format 44100:16:2 sostituirlo con 44100:24:2 non ha efficacia.
Anche con mplayer forzandogli demux rawaudio -rawaudio e le varie opzioni che seguono per i suddetti parametri mi risulta che a video vengono acquisiti i parametri da me impostati ma sull'oscillo vedo sempre la stessa frequenza.

Qualcuno mi sa dare una mano ? Oppure mi può indicare a chi potrei rivolgere questa domanda ?


Grazie comunque dell'interesse.

Saluti Stefano Pria

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "BeagleBoard Projects" di Google Gruppi.
Per postare messaggi in questo gruppo, invia un'email a bb_pr...@googlegroups.com.
Per annullare l'iscrizione a questo gruppo, invia un'email a bb_projects+unsubscribe@googlegroups.com.
Per ulteriori opzioni, visita il gruppo all'indirizzo http://groups.google.com/group/bb_projects?hl=it.


Alfonso Martone

unread,
Nov 1, 2012, 5:35:23 PM11/1/12
to bb_pr...@googlegroups.com
L'interfaccia audio � un device a cui va inviata la forma d'onda da
mandare alle casse. Sotto Linux appare come un file ("/dev/dsp") su cui
scrivere quei dati (read: "campionamento"; write: "output audio"; ioctl:
"volume, frequenza output, ecc."): il kernel, non ha appena ha
abbastanza dati da mandare in output (dovrebbero essere 512 bytes, cio�
256 samples a 16 bit, ossia poco meno di 6 millisecondi di audio a 44.1
KHz) attiva il chip audio e gli manda il blocco dati.

Dato che la periferica ha solo due uscite (perch� � stereo), nel corso
degli anni hanno inventato qualche "daemon" che raccoglie i dati audio,
li mixa e poi li manda al kernel (i vari Enlightenment Sound Daemon,
Pulseaudio, eccetera), con un overhead generalmente trascurabile. A suo
tempo l'ALSA era nato per ovviare ai limiti del vecchio OSS, col
risultato che ALSA � diventato pi� complicato di OSS.

L'unico motivo per usare direttamente "/dev/dsp" � avere un assoluto
fine-control di quello che stai mandando in output (oppure di avere
qualcosa di estremamente semplice da provare; invece, studiarsi le
librerie di pulseaudio, significa dover spendere per forza qualche ora
in pi� sul progetto).

Andare a un livello ancora pi� basso � un'impresa titanica, che magari
qualche professore universitario potrebbe chiedere come tesi di ricerca
per la laurea. La manualistica tecnica degli OMAP � di parecchie
migliaia di pagine (non per modo di dire).

I sorgenti del kernel Linux per la Beagleboard pi� aggiornati li si
trovano sul github di Koen Kooi ( https://github.com/koenkooi/ ) ma non
credo che in pochi giorni di accanito studio si possano cavare chiss�
che informazioni. Il fatto � che il kernel Linux � ormai cos� grosso,
che per studiare "una" periferica hardware occorre destreggiarsi tra
parecchi file sorgenti che spesso apparentemente non c'entranno niente,
faticando parecchio a trovare il bandolo della matassa... Parlo cos�
perch� gi� ai tempi di Linux 1.2.x per scrivere un modulino che usasse
il DMA per uno scanner manuale, fui costretto a sudare sette camicie.



Reply all
Reply to author
Forward
0 new messages