Porting newlib a una configurazione ARM personalizzato

Question

questo è il mio primo post, e si estende su una cosa che ho cercato di ottenere a lavorare su e fuori per circa un anno.

In sostanza si riduce a quanto segue: ho una copia di newlib che sto cercando di ottenere lavorando su un LPC2388 (un ARM7TDMI da NXP). Questo è su una macchina Linux con braccio-elf-gcc

La domanda che ho è che ho cercato in un sacco di tutorial parlando di porting newlib, e tutti parlano gli stub (come l'uscita, aperto, lettura / scrittura, sbrk), e ho una bella buona idea di come implementare tutte queste funzioni. Ma , dove dovrebbe li metto?

Ho la distribuzione newlib da sources.redhat.com/pub/newlib/newlib-1.18.0.tar.gz e dopo rovistando ho trovato "syscalls.c" (in newlib-1.18.0 / newlib / libc / sys / braccio) che contiene tutti gli stub, che devo aggiornare, ma sono tutti riempito con piuttosto finito di guardare il codice (che fa non sembrano funzionare senza il crt0.S, che in sé non funziona con il mio chip).

Devo solo essere spazzando via quelle funzioni me stesso, e li ri-scrittura? O dovrei scriverle da qualche altra parte. Devo fare una nuova cartella in newlib / libc / sys con il nome del mio "architettura" e cambiare l'obiettivo di abbinare?

Sono anche curioso di sapere se c'è un'etichetta di comportamento sulla distribuzione di qualcosa di simile dopo aver rilasciato come progetto open source. Al momento ho uno script che scarica Binutils, braccio-elf-gcc, newlib, e gdb, e li compila. Se sto modificare i file che si trovano nella directory newlib, dovrei consegnare una patch che si applica automaticamente il mio script? O devo aggiungere il newlib modificato nel repository?

Grazie per preoccuparsi di leggere! A seguito di questa è una ripartizione più dettagliata di quello che sto facendo.

---

Per chi vuole / bisogno di più informazioni circa la mia messa a punto:

Sto costruendo una console ARM videogioco basato liberamente sul progetto Uzebox ( http://belogic.com/uzebox/ ).

Ho fatto un sacco di cose che tirano da un sacco di risorse diverse, come cerco di capirlo. È possibile leggere l'inizio delle mie avventure qui (forum SparkFun, nessuno risponde, come ho capirlo da solo): forum.sparkfun.com/viewtopic.php?f=11&t=22072

ho seguito tutto questo leggendo attraverso le domande StackOverflow circa porting newlib e vide alcuni dei diversi tutorial (come wiki.osdev.org/Porting_Newlib), ma anche soffrono dicendomi di utensileria stub senza menzionare dove, chi , cosa, quando, e come!

Answer 1

  

Ma dove non li metto?

È possibile metterli dove vuoi, fintanto che esistono nel link finale. Si potrebbe incorporarli nella libreria libc stessa, o si potrebbe mantenere quella generica, e hanno le chiamate di sistema come un file oggetto target specifico separato o libreria.

Potrebbe essere necessario creare i propri crt0.s bersaglio specifici ed assemblaggio e collegarlo per la vostra destinazione.

Un buon tutorial di Miro Samek di salti quantici su come ottenere lo sviluppo di GNU / ARM installato e funzionante è disponibile qui . Gli esempi si basano su una parte Atmel AT91 quindi hai bisogno di conoscere un po 'il dispositivo NXP per adattare il codice di start-up.

Un pronto fatta Newlib strato di porting per LPC2xxx è stata qui , ma i collegamenti ot teh file sembrano essere rotto. Lo stesso strato porting è usato in Martin Thomas' WinARM progetto. Questo è un porto di Windows di GNU GCC ARM, ma gli esempi inclusi in esso sono specifici di destinazione non specifico host.

Si dovrebbe solo bisogno di modificare il livello di porting su Newlib, e dato che è bersaglio e specifica applicazione, non è necessario (in realtà probabilmente non dovrebbe) inviare il tuo codice al progetto.

Answer 2

Quando ero con newlib che è esattamente quello che ho fatto, ha spazzato via crt0.s, syscalls.c e libcfunc.c. La mia preferenza personale è stato quello di anello della sostituzione per crt0.s e syscalls.c (laminati le poche funzioni libcfunc in sostituzione syscalls.c) in base alla applicazione embedded.

Non ho mai avuto un interesse a spingere nulla di tutto ciò di nuovo lavoro nella distro, quindi non può aiutare a lì.

Sei sulla strada giusta, però, crt0.S e syscalls.c sono dove si desidera lavorare da personalizzare per il vostro target. Personalmente ero interessato a una libreria C (e printf) e sarebbe in primo luogo neutro tutte le funzioni per restituire 0 o 1 o qualsiasi cosa per ottenere la funzione di solo lavoro e non ottenere nel modo di collegare, periodicamente rendendo il file funzioni / O operano su collegati in dati in rom / ram. Fondamentalmente senza sostituire o modificare qualsiasi altro file in newlib ho avuto una buona dose di successo, così si è sulla strada giusta.