Documentazione MCU e CPU

[IsidoroKZ]

La mia curiosita` era per un utente che volesse svilupparsi una scheda con del sw, non produzione industriale in cui si deve fare il test. Con tutti i manuali ci sono sufficienti informazioni per fare uno hardware funzionante e scrivere del sw senza dover usare dei driver prodotti da chi conosce il chip, come invece capita normalmente con le GPU?

[TardoFreak]

Si.

[xyz]

Tutte le CPU e molte MCU e credo anche le GPU sono ormai BIST (Built-in self-test) da più di un decennio. Vengono eseguiti una serie di test interni su ogni parte prima di eseguire la prima istruzione. Ad esempio le CPU Intel sono BIST e restituisco nei registri (EAX, EBX, ecc..) il report del BIST:

http://datasheets.chipdb.org/Intel/x86/Pentium/Embedded%20Pentium%AE%20Processor/INITCONF.PDF

se c'è un errore il BIOS riporta l'errore (a video, segnali acustici ecc...) e ferma tutto. Una volta controllato lo stato della CPU il BIOS esegue il POST (Power-On Self-Test):

http://en.wikipedia.org/wiki/Power-on_self-test

vengono controllate tutti i chip collegati, in particolar modo la RAM, solo dopo viene fatto partire il sistema operativo.

Anche ARM è BIST:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0242b/Cjhehdde.html

e se il chip ha anche della memoria viene testata (MBIST):

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0284g/Babjfbhb.html

Esternamente le CPU possono essere testate via JTAG, in questo modo di ha un totale controllo dei registri e dei pin con il boundary scan, come detto da posta10100. Un altro test molto semplice è il controllo della corrente assorbita dalla CPU, se è zero o è troppa la CPU non funziona (questo test non rivela se la CPU assorbe la giusta corrente ma è fallata).

In altre parole è in fabbricante della CPU a testare la CPU internamente, chi meglio di lui sa come funziona.

[xyz]

La Broadcom ha rilasciato la documentazione e i sorgenti completi dei driver OpenGL-ES 1.1 e 2.0 della GPU VideoCore® IV 3D presente nel SoC BCM2835 usato dalla Raspberry-Pi:

http://blog.broadcom.com/chip-design/an ... e-kingdom/

[Shockwaver]

xyz
.... Fantastico post in [9] conoscenza e capacità di sintesi che per me non hanno dell'umano
Volevo solo aggiungere comunque che per quanto riguarda gli ARM, i 7 e i 9 che hanno rispettivamemte archittettura CISC (von-Neumann) e RISC con cache (la cosiddetta modified Harvard, tra i primi ad implementarla), onestamente non credo di aver mai trovato una documentazione completa.

[thexeno]

Credevo che per CPU come le Intel, l'unica documentazione "pubblica" o che non richiede la necessità di ordini industriali fosse quella di programmazione: avevo trovato in un ufficio un set di 5 manuali stampati da Intel per la programmazione x86, dedicata a qualche generazione in particolare come il P4 (non ricordo esattamente quale). Una specie di documentazione come quella del "finto" datasheet del BCM2835 che serve ai programmatori. Poi se cerco datasheet, invece, trovo solo quelli "introduttivi" di 40 pagine per intenderci. Datasheet che non trovo per gli AMD...

Ah, avevo una vecchia GPU PCI della SIS in casa: il chip aveva un datasheet completo, ma parlo di hw di 15 anni fa o poco più. Credo fosse un caso più unico che raro.

Quindi la situazione, se ho capito bene, è che uno può farsi un progetto completo, ma solo se sceglie le CPU o componenti documentate? (nel senso che esistono documentazioni in fasce di un certo livello?) xyz ha detto che le CPU Intel sono ben documentate: significa che io potrei, cpaacità permettendo, mettere su un sistema basato ad esempio su un Pentium III? O si riferiva alla programmazione? Per datasheet completo mi riferisco, per non cadere nell'equivoco, a un datasheet completo, con tanto di documentazione elettrica annessa, che se non c'è mi rende impossibile sviluppare la mia schedina che supporta il chip, ammesso di saperlo programmare completamente. Ovvero, al post [11] di Isidoro seguito da una conferma di TardoFreak, fino a che livello può valere quel "Sì"?

Sbaglio a pensare che per sviluppare un SW molto stretto all'HW o l'hardware stesso, uno dovrebbe per forza lavorare all'Intel o presso qualche importante produttore, ad es. di schede madri? Mentre per il resto, appunto, c'è la classica documentazione per il programmatore e basta.

[thexeno]

[OT]

La Broadcom ha rilasciato la documentazione e i sorgenti completi dei driver OpenGL-ES 1.1 e 2.0 della GPU VideoCore® IV 3D presente nel SoC BCM2835 usato dalla Raspberry-Pi:

http://blog.broadcom.com/chip-design/an ... e-kingdom/

Tra l'altro, significa che non ci saranno più limitazioni sul Rasp? Potrei commuovermi, cioè è una notiziona
[/OT]

[thexeno]

Tra l'altro, si può usare un micro come se fosse una CPU stand alone.. bello (chissà quanto utile però, e se si faccia davvero in certi casi reali)
http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit

[xyz]

Tra l'altro, si può usare un micro come se fosse una CPU stand alone..

Per definizione stessa un micro controllore è anche una CPU e può funzionare per la gran parte dei casi stand alone. Il contrario molto spesso non è vero, le CPU usate nei sistemi desktop vogliono chip aggiuntivi di supporto,

Il link che hai riportato lo conosco molto bene, si tratta di far eseguire Linux in un micro controllore a 8 bit, compito quasi impossibile visto che Linux nasce per girare con CPU con registri di almeno 32 bit. Soluzione geniale, scrivere per AVR un emulatore per una vecchia versione di ARM (molto più semplice come architettura rispetto alle ultime versioni) ancora sopportato dal compilatore GCC e far girare Linux nel emulatore. Per avere tanta RAM ha creato una interfaccia hardware verso una vecchia SIMM simulando anche il comportamento di una MMU. Il tutto comunque è molto lento.

[thexeno]

Tra l'altro, si può usare un micro come se fosse una CPU stand alone..

Per definizione stessa un micro controllore è anche una CPU e può funzionare per la gran parte dei casi stand alone. Il contrario molto spesso non è vero, le CPU usate nei sistemi desktop vogliono chip aggiuntivi di supporto,

Chiaro, mi riferivo più precisamente al fatto che essendo una mcu un mini computer con una sua cpu, lo spazio di indirizzamento è implementato (in hw?) per accedere direttamente alla RAM interna. Non ho i piedini di indirizzo direttamente accessibili all'esterno, non di solito almeno. Mentre appunto normalmente in una cpu la cosa è la stessa ma su ram esterna.
Mi chiedevo quindi se ci sono per caso applicazioni (non parliamo di chip fpga & co.) che ricadono in questa "modifica" di accesso a una RAM esterna per le istruzioni, tramite MCU.

Il link che hai riportato lo conosco molto bene, si tratta di far eseguire Linux in un micro controllore a 8 bit, compito quasi impossibile visto che Linux nasce per girare con CPU con registri di almeno 32 bit. Soluzione geniale, scrivere per AVR un emulatore per una vecchia versione di ARM (molto più semplice come architettura rispetto alle ultime versioni) ancora sopportato dal compilatore GCC e far girare Linux nel emulatore. Per avere tanta RAM ha creato una interfaccia hardware verso una vecchia SIMM simulando anche il comportamento di una MMU. Il tutto comunque è molto lento.

qualcosa come 4 ore per un boot completo, una cpu con velocità effettiva di qualche kHz. Mi piacciono queste cose perché, secondo me, ti fanno "percepire" l'ordine di grandezza del lavoro che deve fare una CPU (o in generale un qualsiasi sistema), per compiere anche l'operazione apparentemente più semplice.