Link alla notizia: http://www.hwupgrade.it/news/sistemi/chip-il-computer-da-9-dollari-sbanca-su-kickstarter_57194.html

Quella dei computer da una manciata di dollari è una categoria molto interessante che apre a scenari d'uso particolarmente variegati. Si aggiunge adesso CHIP, computer da 9$ che all'occorrenza può trasformarsi in dispositivo mobile

Click sul link per visualizzare la notizia.

estiqaatsi speriamo girino in quantità ci sono tante piccole cose utili da farci

spiegatemi come funziona sto kickstarter. loro chiedono 50000$ e ne ricevono 630000$. le domande sono due:
1) i soldi in eccesso che fine fanno
2) perche la gente, una volta che hanno visto che il target di 50000$ è stato raggiunto, continuano a mandare soldi???

spiegatemi come funziona sto kickstarter. loro chiedono 50000$ e ne ricevono 630000$. le domande sono due:
1) i soldi in eccesso che fine fanno
2) perche la gente, una volta che hanno visto che il target di 50000$ è stato raggiunto, continuano a mandare soldi???

Dall'articolo sembrava che quei soldi venissero dati come pagamento anticipato per il prodotto. Raggiunta la cifra minima iniziano ad evadere (gli ordini, non le tasse :D)

insomma un piccolo RasperryPi...
...e poi "Piccolo PC"... con un Allwinner A13 ... quanta potenza può erogare...?
in altre parole, che ci fai !!!!??

spiegatemi come funziona sto kickstarter. loro chiedono 50000$ e ne ricevono 630000$. le domande sono due:
1) i soldi in eccesso che fine fanno
2) perche la gente, una volta che hanno visto che il target di 50000$ è stato raggiunto, continuano a mandare soldi???

come e' stato detto molti 'donano' quando in realta' si tratta di un preorder alla fine. Comunque quando viene sfondato il tetto prestabilito di solito consente alla ditta di procedere piu' in grande e magari di migliorare ulteriormente il prodotto se possibile.

A conti fatti, è un raspi2 più limitato... ma se ci si aggiungono gli accessori e lo si rende "pari" (anche solo un hdmi o vga), alla fine come prezzo siamo lì...

lo stato per prendere..ma alla fine, tra 20$ di spedizione, e un modulo hdmi..spendo 44$..praticamente il prezzo del raspberry pi 2 su amazon..ma meno potente..ci ho ripensato :P

spiegatemi come funziona sto kickstarter. loro chiedono 50000$ e ne ricevono 630000$. le domande sono due:
1) i soldi in eccesso che fine fanno
2) perche la gente, una volta che hanno visto che il target di 50000$ è stato raggiunto, continuano a mandare soldi???
1) vanno sempre a chi li ha chiesti
2) perchè chi dà soldi gli promettono qualcosa in cambio (se tutto va in porto), vedi la colonna sulla destra su kickstarter?
La cifra richiesta è solo la cifra minima, se prendono meno di quello i soldi ritornano indietro ai vari partecipanti.

praticamente il prezzo del raspberry pi 2 su amazon..ma meno potente..ci ho ripensato :PRpensaci ancora.
il raspi 2 ha tutto su una SINGOLA USB 2.0. Questo ne ha due, e sono entrambe native. Processore è palesemente meglio, GPU anche.
http://linux-sunxi.org/A13

Inoltre contiene il decoder hardware CedarX, che pialla e contropialla il decoder del raspi http://linux-sunxi.org/CedarX

Rpensaci ancora.
il raspi 2 ha tutto su una SINGOLA USB 2.0. Questo ne ha due, e sono entrambe native. Processore è palesemente meglio, GPU anche.
http://linux-sunxi.org/A13


Sbagliatissimo.
L'unica cosa che è collegata sul bus USB è la porta ethernet. Dal momento che il bus USB ha un'ampiezza di banda di 480 Mbps e la ethernet è 100 Mbps, ci sta dentro abbastanza bene.

Il processore di questo cosino è una cagatina, un allwinner a13 single core. Vatti a cercare le performance della fpu degli allwinner a1x e poi ne riparliamo. Per non parlare della documentazione VPU e in generale: è un chip cinese.


Inoltre contiene il decoder hardware CedarX, che pialla e contropialla il decoder del raspi http://linux-sunxi.org/CedarX

Te ne fai ben poco se non hai un adeguato supporto software, e quello degli allwinner non è nemmeno lontanamente paragonabile ai raspberry.

Te ne fai ben poco se non hai un adeguato supporto software, e quello degli allwinner non è nemmeno lontanamente paragonabile ai raspberry.

Già, senza contare le violazioni multiple delle licenze GPL ed LGPL da parte di Allwinner Technology.

Visto che sono chip che si trovano su un sacco di tablet ed aggeggi, c'e' già una community che ci lavora sopra (nonostante il comportamente a dir poco scorretto del produttore), ma usarlo per un prodotto simil-Arduino o simil-Raspberry non mi sembra
il massimo.

Sbagliatissimo.
L'unica cosa che è collegata sul bus USB è la porta ethernet.il SoC ha una singola porta USB, sulla scheda c'è un chip di un hub, e su quell'hub c'è l'ethernet e le altre porte USB.
Il processore di questo cosino è una cagatina, un allwinner a13 single core.ARMv7 da 1 Ghz contro un ARMv6 da 700?
Quello quadcore francamente non lo comprendo. Con una sola USB non va lontano.
Vatti a cercare le performance della fpu degli allwinner a1x e poi ne riparliamo. è una VFPv3 standard, che performance vuoi che abbia?

Per non parlare della documentazione VPU e in generale: è un chip cinese.Mentre invece Broadcom che non è cinese e ha rilasciato la documentazione per il raspi? Non mi pare. Hanno rilasciato roba per chip simili lasciando la gente a :mc: per far andare la roba.

Te ne fai ben poco se non hai un adeguato supporto software, e quello degli allwinner non è nemmeno lontanamente paragonabile ai raspberry.Intanto ha un processore ARMv7 quindi supportato dalle distro linux standard che supportano ARM (al contrario del Raspi), non devi ricompilare nulla.

Per il resto devi usare i blob come per il raspi o come per tutti i SoC non Intel.

Ma esiste fino ad ora qualcosa che attraverso Kickstarter sia stata infine anche prodotta e venduta normalmente? Oppure: di cento cose diverse che appaiono su Kickstarter, circa quante poi vengono prodotte e circa in che quantità vendute?

il SoC ha una singola porta USB, sulla scheda c'è un chip di un hub, e su quell'hub c'è l'ethernet e le altre porte USB.


Appunto, non è come dici tu che è "tutto sulla porta USB".
Solo la ethernet condivide l'ampiezza di banda delle porte USB.


ARMv7 da 1 Ghz contro un ARMv6 da 700?
Quello quadcore francamente non lo comprendo. Con una sola USB non va lontano.


Siccome non lo comprendi, non lo consideri. Mi pare piuttosto fazioso. Confrontiamo il broadcom quadcore a 900 mhz dei raspi2 con i vari allwinner e già il gioco diventa più interessante, visto che anche il quadcore è un ARMv7 Cortex-A7.
In fondo il raspi1 da quanti anni che è in giro? 4 o 5 credo...


è una VFPv3 standard, che performance vuoi che abbia?


http://www.rkblog.rk.edu.pl/w/p/quick-look-cubieboard-micro-computer-allwinner-a10-arm-cpu/

c'erano anche altri benchmark sulle performance della fpu dell'a10, ma non riesco più a trovarli.


Mentre invece Broadcom che non è cinese e ha rilasciato la documentazione per il raspi? Non mi pare. Hanno rilasciato roba per chip simili lasciando la gente a :mc: per far andare la roba.

Difatti la quantità di materiale disponibile per raspberry è proprio uguale a quella disponibile per allwinner, dove invece bisogna andare di reverse engineering.
Ma fammi il piacere, se ho un problema con raspberry posso andare sul forum e contattare uno sviluppatore del kernel. Se ho un problema con allwinner mi attacco al tram!


Intanto ha un processore ARMv7 quindi supportato dalle distro linux standard che supportano ARM (al contrario del Raspi), non devi ricompilare nulla.


Il raspi2 è ARMv7 regolare. E forse tu parli di "distro linux standard" intendendo Debian. Il supporto alla fpu hardware (armhf) con Debian parte dalla VFPv3 dell'ARMv7. Se ti accontenti dell'emulazione software (armel) della FPU, anche debian gira su ARMv6.
Arch Linux, da quello che leggo dalla loro homepage, supporta la fpu hardware già dal set di istruzioni ARMv6.


Per il resto devi usare i blob come per il raspi o come per tutti i SoC non Intel.

L'unico blob di cui sono a conoscenza sul raspberry è rimasto il firmware che viene caricato al boot e che contiene il sistema operativo realtime proprietario che gira sulla GPU (start.elf)

lo stato per prendere..ma alla fine, tra 20$ di spedizione, e un modulo hdmi..spendo 44$..praticamente il prezzo del raspberry pi 2 su amazon..ma meno potente..ci ho ripensato :P

A 50$ c'è anche il bananapi ben accessoriato (scheda + box + alimentatore + cavo usb + cavo sata + dissipatore) che è non poco superiore a questo CHIP.

Boh, a meno di volerlo usare nella sua versione ultrabase limitata, sinceramente non trovo la convenienza, economica e "tecnica" rispetto ad un raspi2 o un bananapi (a seconda dell'uso).

Appunto, non è come dici tu che è "tutto sulla porta USB".
Solo la ethernet condivide l'ampiezza di banda delle porte USB.Quindi che lo storage primario E la rete condividano lo stesso bus non ti infastidisce? A me sì e tanto.


Siccome non lo comprendi, non lo consideri. Mi pare piuttosto fazioso. Confrontiamo il broadcom quadcore a 900 mhz dei raspi2 con i vari allwinner e già il gioco diventa più interessante, visto che anche il quadcore è un ARMv7 Cortex-A7.Con la stessa limitazione della USB e che costa 4 volte tanto questo coso qui. Che ti serve un processore potente quando tutti i dati passano per una USB?
Diamine un Kirkwood singlecore da 800mhz (ARMv5) che trovo a 30 euro con scatola e usb 3.0 multiple gli dà la paga come velocità di trasferimento dati.
Questo limita gli utilizzi di parecchio, almeno per quello che ci faccio io.

In fondo il raspi1 da quanti anni che è in giro? 4 o 5 credo...2012. Per i sistemi embedded è una enormità di tempo.

http://www.rkblog.rk.edu.pl/w/p/quick-look-cubieboard-micro-computer-allwinner-a10-arm-cpu/
c'erano anche altri benchmark sulle performance della fpu dell'a10, ma non riesco più a trovarli.Sappiamo benissimo entrambi che un test del 2013 non significa nulla, specialmente quando dei test sono anche falliti (indicando scarso supporto del programma di benchmark).

Difatti la quantità di materiale disponibile per raspberry è proprio uguale a quella disponibile per allwinner, dove invece bisogna andare di reverse engineering.Sbaglio o la fondazione ha offerto 10'000 dollari a chi gli riesce a reverse-ingegnerizzare i driver video? Ora stanno per andare in mainline (kernel 4.1 forse).
Broadcom aveva pubblicato roba parziale di un altro SoC.

Ma fammi il piacere, se ho un problema con raspberry posso andare sul forum e contattare uno sviluppatore del kernel. Se ho un problema con allwinner mi attacco al tram!
i SoC allwinner sono supportati dal team Sunxi, quindi se ti serve aiuto chiedi a loro http://linux-sunxi.org/Main_Page
E forse tu parli di "distro linux standard" intendendo Debian.No, se dico "distro linux standard" intendo il 'Buntu, Fedora, Slackware, Gentoo, et al. Su Arm7 (quindi FPU obbligatoria) gira un pò di tutto.
Su ARMv6 (FPU non obbligatoria e in genere non standard)... no

Debian e ALARM (arch linux ARM) girano ovunque (anche su ARM5), ma si sapeva.

L'unico blob di cui sono a conoscenza sul raspberry è rimasto il firmware che viene caricato al boot e che contiene il sistema operativo realtime proprietario che gira sulla GPU (start.elf)Senza quel coso non parte neanche eh.

Con la stessa limitazione della USB e che costa 4 volte tanto questo coso qui. Che ti serve un processore potente quando tutti i dati passano per una USB?
Diamine un Kirkwood singlecore da 800mhz (ARMv5) che trovo a 30 euro con scatola e usb 3.0 multiple gli dà la paga come velocità di trasferimento dati.
Questo limita gli utilizzi di parecchio, almeno per quello che ci faccio io.


Esatto, dipende da quello che ci fai/vuoi fare.

Prima io il raspi lo usavo come serverino di download (torrent/pyload e simili). Perchè "usavo? Semplice, proprio per quel problema di bus usb.

Per i download usavo un disco usb, e il trasferimento deve avvenire tramite ethernet, il risultato erano velocità nell'ordine dei 7-8 MB/s su una rete gigabit.
Inoltre il semplice trasferimento dati mandava la cpu al 100% (no, non usavo ntfs) quindi per raggiugnere quelle velocità dovevo bloccare tutti i processi.
Inaccettabile, specie quando devi trasferire 50-100-200gb.

L'ho cambiato con un bananapi: cpu nettamente più potente, ethernet gigabit nativa, un bus usb 2.0 nativo e dedicato per ogni singola porta, porta sata nativa...
Trasferisco a 20-25 MB/s (limite di usb2) senza dover terminare processi o quant'altro.

Il raspi? Grazie a rasplex (un client openelec personalizzato per plex scritto apposta e solo per raspi 1 e 2) lo uso con estrema soddisfazione per vedere i contenuti del mio mediaserver su qualunque TV.

Però, a pensarci bene, per questi due usi quel "chip" soffre di limitazioni mica trascurabili.

Download server: non ha una presa ethernet, quindi bisognerebbe fare tutto tramite wifi. Quanto prende? È stabile e affidabile anche sul lungo periodo e per lunghi trasferimenti? Qual'è la velocità? Insomma, in questi casi il cavo non si batte.

Media client: la presa HDMI è a parte, e il costo del tutto raggiunge i 24$. A quel punto, meglio un raspi, che è notevolmente più supportato e puoi tranquillamente aggiungere una chiavetta esterna con antenna (la ricezione migliora notevolmente) o un access point usato come client e collegato alla ethernet. Inoltre hai due/quattro porte usb per collegarci quello che ti pare/serve.

Questo chip attira per il prezzo ridicolo... però è anche notevolmente limitato, e se ci aggiungi accessori il prezzo si allinea agli altri. Raspi (con i suoi limiti) e bananapi sono decisamente più flessibili.

Quindi che lo storage primario E la rete condividano lo stesso bus non ti infastidisce? A me sì e tanto.


Bah, fintanto che le performance per fare quello che ci devo fare sono sufficienti, non vedo perchè dovrei essere infastido da una scelta di design. Se proprio ho bisogno di performance particolari, allora chiaramente opto per un prodotto diverso. Preferibilmente con un SoC decente.
E poi lo storage primario è la microSD, che ha il suo collegamento punto-punto con il SoC e non passa da USB.


Con la stessa limitazione della USB e che costa 4 volte tanto questo coso qui. Che ti serve un processore potente quando tutti i dati passano per una USB?
Diamine un Kirkwood singlecore da 800mhz (ARMv5) che trovo a 30 euro con scatola e usb 3.0 multiple gli dà la paga come velocità di trasferimento dati.
Questo limita gli utilizzi di parecchio, almeno per quello che ci faccio io.


Ho capito benissimo che qui si parla del tuo caso d'uso. La cosa che infastidisce me è che il tuo personalissimo caso d'uso diventa il metro di paragone.
Il mio caso d'uso è un po' diverso e ti assicuro che se non ci fosse stato un supporto decente, una documentazione decente ed anche una community dietro, non avrei potuto realizzare niente.



2012. Per i sistemi embedded è una enormità di tempo.

Sappiamo benissimo entrambi che un test del 2013 non significa nulla, specialmente quando dei test sono anche falliti (indicando scarso supporto del programma di benchmark).


Appunto. Il confronto è impari, visto che si parla di tecnologia vecchia di tre anni e più confrontata con roba che è uscita magari un anno fa. Confrontando con il raspberry pi2 già è diverso per via della cpu rinnovata.
E tieni anche presente che raspberry pi 1 e raspberry pi 2 sono binary compatible, quindi tutto quello ceh gira sul pi1 gira tale e quale sul pi2, cosa direi fondamentale in ambito industriale.


Sbaglio o la fondazione ha offerto 10'000 dollari a chi gli riesce a reverse-ingegnerizzare i driver video? Ora stanno per andare in mainline (kernel 4.1 forse).
Broadcom aveva pubblicato roba parziale di un altro SoC.


Sbagli. Broadcom ha pubblicato i sorgenti del driver del kernel di un altro SoC che monta il videocore IV, che è la stessa GPU del raspberry Pi.


i SoC allwinner sono supportati dal team Sunxi, quindi se ti serve aiuto chiedi a loro http://linux-sunxi.org/Main_Page
No, se dico "distro linux standard" intendo il 'Buntu, Fedora, Slackware, Gentoo, et al. Su Arm7 (quindi FPU obbligatoria) gira un pò di tutto.
Su ARMv6 (FPU non obbligatoria e in genere non standard)... no

Debian e ALARM (arch linux ARM) girano ovunque (anche su ARM5), ma si sapeva.


La community è sempre una gran cosa, ma francamente non ci farei niente che non sia qualcosa di puramente hobbystico su un prodotto con un SoC di un produttore che osteggia pesantemente la sua stessa community.


Senza quel coso non parte neanche eh.

E' il suo "bios", mi pare piuttosto regolare. Non avendo eMMC a bordo da qualche parte lo deve prendere. Anche i SoC Intel avranno il loro bravo firmware proprietario da qualche parte.

Bah, fintanto che le performance per fare quello che ci devo fare sono sufficienti, non vedo perchè dovrei essere infastido da una scelta di design.La domanda diventa "e tu che ci fai?" però.

E poi lo storage primario è la microSD, che ha il suo collegamento punto-punto con il SoC e non passa da USB.Quella è la partizione di sistema al max. Non ha senso mettere una SD da 128GB in un raspi.

Ho capito benissimo che qui si parla del tuo caso d'uso. La cosa che infastidisce me è che il tuo personalissimo caso d'uso diventa il metro di paragone.Dimmi il tuo caso d'uso e vediamo.

Se vuoi un media center ci sono scelte migliori a prezzi comparabili (se contiamo anche scatola, alimentatore ecc).

Se vuoi un nas/media-server pure.

Come scheda di sviluppo (=utilizzi dove i pin GPIO servono a qualcosa) boh, non ha nulla di speciale, ma non avere una porta per lo storage decente e un ethernet serio è imperdonabile secondo me.

Tutte le elaborazioni o la trasmissione dati ne risentono di brutto, quindi o è un giochino o è un client.

E tieni anche presente che raspberry pi 1 e raspberry pi 2 sono binary compatible, quindi tutto quello ceh gira sul pi1 gira tale e quale sul pi2, cosa direi fondamentale in ambito industriale.??????
Semmai era il raspi1 che avendo una FPU non standard (come gli ARMv6) ha richiesto sbattimento e una specie di fork di Debian (Raspbian appunto).

Dagli ARMv7 sono tutti uguali.

Sbagli. Broadcom ha pubblicato i sorgenti del driver del kernel di un altro SoC che monta il videocore IV, che è la stessa GPU del raspberry Pi.Il porting non è stato una passeggiata, i sorgenti erano del driver di Android. I sottosistemi grafici di Android sono diversi da quelli standard di linux.

La community è sempre una gran cosa, ma francamente non ci farei niente che non sia qualcosa di puramente hobbystico su un prodotto con un SoC di un produttore che osteggia pesantemente la sua stessa community.Se devo fare qualcosa di serio gli pago 4000 sacchi o quello che è e mi danno un SDK, la licenza di usarlo, e il supporto del produttore.

E' il suo "bios", mi pare piuttosto regolare.I sistemi embedded non hanno BIOS. l'OS è il firmware della scheda (ciò che è il BIOS in un PC). C'è al max un bootloader relativamente intelligente.

La domanda diventa "e tu che ci fai?" però.


Un sistema distribuito dove ogni nodo della rete riproduce video HD (da 2 a 20 mbps di picco) e mostra grafiche realizzate con OpenVG attraverso l'uscita HDMI a 720p. I video sono scaricati da internet attraverso una connessione crittografata in background e salvati come cache su una memoria USB oppure sulla microSD, anch'esse crittografate. Inoltre in background girano diversi demoni che scaricano altri dati (meteo, webcam, eventi, contenuti personalizzati del cliente, etc...) e tutto deve funzionare 24/7 senza intervento manuale, dato che i dispositivi sono dislocati in posizioni remote.

Non proprio un NAS


Quella è la partizione di sistema al max. Non ha senso mettere una SD da 128GB in un raspi.


Quello che per te non ha senso per gli altri può averlo. Nel mio caso, ha senso.


Se vuoi un media center ci sono scelte migliori a prezzi comparabili (se contiamo anche scatola, alimentatore ecc).

Se vuoi un nas/media-server pure.


Senza dubbio, ma io sono il primo che valuta le board in giro, anche per motivi professionali.
Purtroppo nessuna ha il supporto che ti garantisce la raspberry foundation.
Per cazzeggio invece penso che prima o poi prenderò un odroid c1.


Come scheda di sviluppo (=utilizzi dove i pin GPIO servono a qualcosa) boh, non ha nulla di speciale, ma non avere una porta per lo storage decente e un ethernet serio è imperdonabile secondo me.

Tutte le elaborazioni o la trasmissione dati ne risentono di brutto, quindi o è un giochino o è un client.


Come tutte le macchine. Però nella mia situazione avere community, staff e documentazione a disposizione è più importante che trasferire file a 50 mb/s sulla ethernet.


??????
Semmai era il raspi1 che avendo una FPU non standard (come gli ARMv6) ha richiesto sbattimento e una specie di fork di Debian (Raspbian appunto).

Dagli ARMv7 sono tutti uguali.


Quello dell'ARMv6 è una VFPv2, non ho idea di dove hai letto che è "non standard". Se fosse come dici non sarebbe possibile avere compatibilità binaria fra rpi1 e rpi2, invece tutto ciò che viene compilato per rpi1 funziona anche su rpi2 senza bisogno di ricompilare niente.


Il porting non è stato una passeggiata, i sorgenti erano del driver di Android. I sottosistemi grafici di Android sono diversi da quelli standard di linux.


Beh in parte. Android ha sotto linux, infatti in 1 mese circa uno sviluppatore indipendente è riuscito a far girare Quake III sullo stack opensource e si è beccato i 10 keuro:
http://www.phoronix.com/scan.php?page=news_item&px=MTY1MDE


Se devo fare qualcosa di serio gli pago 4000 sacchi o quello che è e mi danno un SDK, la licenza di usarlo, e il supporto del produttore.

I sistemi embedded non hanno BIOS. l'OS è il firmware della scheda (ciò che è il BIOS in un PC). C'è al max un bootloader relativamente intelligente.

Glisso sulla parte di pagare per avere la licenza di usarlo, visto che la posizione opposta a quella intrapresa dalla raspberry foundation.

Non ho capito bene poi cosa intendi con l'ultima frase.
Sul raspberry non c'è firmware, a parte una minima porzione di ROM embeddata dentro al SoC per andarsi a cercare la partizione FAT sulla microSD e leggersi bootcode.bin, che a sua volta esegue start.elf, che è il vero e proprio firmware (che io ho chiamato, virgolettato apposta, bios) e che in realtà è un sistema operativo realtime che gira sulla GPU.

I sistemi embedded non hanno BIOS. l'OS è il firmware della scheda (ciò che è il BIOS in un PC). C'è al max un bootloader relativamente intelligente.

Dipende.
Normalmente non c'e' un bios come sui pc, ma ci possono essere bootloader a più stadi ed altra roba.
Ad esempio sugli Allwinner c'e' un bootloader minimale che carica un bootloader "di configurazione periferiche e GPIO" e poi il bootloader vero e proprio per caricare GRUB, LILO, ecc. che poi caricano i S.O. supportati.

Infatti uno dei problemi nel portare Linux su sistemi non-x86 è che ogni produttore ha un suo standard o un sistema di inizializzazione che varia anche da una famiglia di processori all'altra di uno stesso produttore.

Un sistema distribuito dove ogni nodo della rete riproduce video HD (da 2 a 20 mbps di picco) e mostra grafiche realizzate con OpenVG attraverso l'uscita HDMI a 720p. I video sono scaricati da internet attraverso una connessione crittografata in background e salvati come cache su una memoria USB oppure sulla microSD, anch'esse crittografate. Inoltre in background girano diversi demoni che scaricano altri dati (meteo, webcam, eventi, contenuti personalizzati del cliente, etc...) e tutto deve funzionare 24/7 senza intervento manuale, dato che i dispositivi sono dislocati in posizioni remote.Bello. :)
Non sai quanto mi infastidisca vedere gente che prende una dev board, la mette in una scatolina e la usa per fare cose dove le prende di brutto da dispositivi che costano 20-30 euro in più.
Senza dubbio, ma io sono il primo che valuta le board in giro, anche per motivi professionali.
Purtroppo nessuna ha il supporto che ti garantisce la raspberry foundation.Sei atipico (in senso buono eh), in genere chi fa roba embedded fa cose usa-e-getta. Non dei sistemi dove il sowftware si può aggiornare indipendentemente dall'hardware.
Per fare quello che dici sopra andavano bene un pò tutti i SoC da tablet vari. Certo ti limitano al kernel X e alla libreria Y, ma una volta fatto il firmware chissenefrega e se c'è da fare aggiornamenti che il SDK non ti permette di fare (di solito non è il caso) allora si cambia tutto.

Quello dell'ARMv6 è una VFPv2, non ho idea di dove hai letto che è "non standard". Se fosse come dici non sarebbe possibile avere compatibilità binaria fra rpi1 e rpi2, invece tutto ciò che viene compilato per rpi1 funziona anche su rpi2 senza bisogno di ricompilare niente.le specifiche della architettura ARMv6 lasciano facoltativa l'implementazione di una fpu, quindi un binario che si aspetta che ci sia e magari gira su un SoC senza si incastra o se il firmware è decente gira con la decodifica software (quindi di fatto si incastra).
Dalla architettura ARMv7 la fpu è obbligatoria (appunto perchè hanno riconosciuto la cazzata del lasciare la scelta ad un branco di gatti quali sono quelli che fanno i SoC).

Quello che stai dicendo non ha senso comunque, il raspi 1 ha un ARMv6, il raspi 2 ha un ARMv7.
ARMv7 è retro-compatibile con ARMv6 per ovvie ragioni.
Cioè per dire posso far girare dei binari compilati sul mio NAS zyxel (ARMv5) dentro al mio smartphone (ARMv7 sicuramente perchè ha VFPv3 e NEON, forse ARMv8).

Semmai dici che i firmware scritti per il raspi 1 vanno tranquillamente sul raspi 2. Ma quello è solo perchè il processore ARM in quel SoC è secondario rispetto alla GPU, che è la "CPU" del SoC a livello hardware, quindi a parte il far girare codice compilato per ARMv6 su un ARMv7 il resto dell'hardware è esattamente lo stesso.

Glisso sulla parte di pagare per avere la licenza di usarlo, visto che la posizione opposta a quella intrapresa dalla raspberry foundation.Licenza di usare il SDK.
Poi certo è un ammasso di script di compilazione merdacchiosi con blob (quando va bene) o kernel precompilati da dio solo sa chi e come, con un blob unico che contiene TUTTO e tu puoi fare solo dei ricamini ai bordi o cambiare le icone.
Ma dipende da quello che vuoi farci.
una minima porzione di ROM embeddata dentro al SoC per andarsi a cercareil cosiddetto bootloader hardware, comune dappertutto.
Su dispositivi più aperti va a caricare/eseguire un bootloader software tipo U-Boot dalla NAND che inizializza l'hardare se necessario, poi si occupa di cercare e avviare il firmware del dispositivo (oppure l'OS che dir si voglia).
che è il vero e proprio firmware (che io ho chiamato, virgolettato apposta, bios) e che in realtà è un sistema operativo realtime che gira sulla GPU.Sì, perchè nel Raspi a livello hardware la "CPU" è il VideoCore (quella che chiamiamo GPU, perchè è una GPU, ma comunque è un processore)
Gestisce l'hardware mentre la macchina si avvia ed eventualmente inizializza il processore ARM, il processore ARM è un sottoposto, e lo stesso per il firmware/OS del dispositivo.
Volendo potresti far girare il raspi senza inizializzare mai il processore ARM (se hai un firmware che gira sul VideoCore o se lo chiami da fuori come se fosse una GPU dedicata).

Di fatto il Raspi è la bestemmia suprema all'open (e molti lo hanno fatto presente in passato), perchè quello che chiami "bios" non è solo il firmware della GPU (che vabbè, glie li si lascia fare dai) o un bootloader (e anche qui vabbè, va bene dai) è di fatto un hypervisor hardware closed source (quindi non sai cosa fa), perchè è la GPU quella che comanda/controlla l'hardware in quel SoC (ad esempio, la ram usata dal processore ARM è allocata dal MMU del processore ma passa per la MMU controllata dalla GPU).
Quello che gira nella GPU non lo vedi, punto.
Mentre con un BIOS o anche con un blob proprietario tutto gira sulla CPU quindi si può tenere d'occhio facilmente.

Ad esempio sugli Allwinner c'e' un bootloader minimale che carica un bootloader "di configurazione periferiche e GPIO" e poi il bootloader vero e proprio per caricare GRUB, LILO, ecc. che poi caricano i S.O. supportati.Perchè invece in un PC com'è? :D
Si parte con qualcosa di hardware che inizializza il processore e va a caricare il BIOS (credo fosse nel chipset), il BIOS inizializza un pò tutto l'hardware va a cercare il bootloader nel MBR di un dispositivo di storage o dalla rete, quello nel MBR va a cercarsi un eventuale secondo bootloader nella "partizione riservata di sistema" di windows da 100 mb (questo bootloader è in grado di leggere i dischi criptati dei quali ha la chiave e di leggere le partizioni logiche), che poi trova la partizione col kernel, lo carica e lo avvia.

Linux funziona in modo simile.

Infatti uno dei problemi nel portare Linux su sistemi non-x86 è che ogni produttore ha un suo standard o un sistema di inizializzazione che varia anche da una famiglia di processori all'altra di uno stesso produttore.Frega niente degli standard diversi, sono solo dei bootloader, anche il top del top (U-boot) occupa meno di 1 MB di spazio.
Si va di reverse-egineering con classe.
Basta solo che non ci siano parti criptate o offuscate, o dei sistemi di controllo della firma crittografica del kernel a livello hardware (o non modificabili), tipo il Secure Boot per i PC.
Poi qualcuno gli fa una versione dedicata di Uboot.
vedi qui er gli Allwinner https://github.com/linux-sunxi/u-boot-sunxi/wiki

Frega niente degli standard diversi, sono solo dei bootloader, anche il top del top (U-boot) occupa meno di 1 MB di spazio.

Frega eccome, perche le procedure di installazione ed inizializzazione/mappatura sono tutte differenti, sia per le differenze tra i vari SoC e sia per le differenti interfacce con i bootloader.
Altrimenti ad esempio sarebbe banale fare una build di Android valida per tutti gli ARMv7
che si tira dietro tutti i moduli kernel necessari.

Frega eccome, perche le procedure di installazione ed inizializzazione/mappatura sono tutte differenti, sia per le differenze tra i vari SoCSecondo me ti sei perso che hanno fatto i FDT per dare queste configurazioni al kernel senza doverlo ricompilare a manina per ogni scheda. http://elinux.org/Device_Tree

Per dire, il Debian che gira nel mio Zyxel 325v2 ha un "firmware" (è un debian armel normalissimo, solo distribuito zippato in tar-gz per comodità, fai partizioni, decomprimi e fine) generico uguale per tutti (ci sono vari altri dispositivi supportati nello stesso forum) e basta mettere il FDT corrispondente al dispositivo nella cartella /boot di fianco al kernel.

Certo se usi l'uboot stock devi infilare il FDT dentro al kernel, ma sono due righe da copia-incollare nel terminale.

Rispetto al prendere il sorgente fare modifiche a mano e ricompilare con architettura diversa (se ricompili dentro un dispositivo ARM ci mette un'enormità di tempo) siamo anni luce avanti.

Vabbè che i SoC kirkwood sono totalmente open, tutti i driver in mainline, ma questo è ciò che offrirebbe linux se i produttori di SoC smettessero di fare i bambini.

E Marvell sembra molto contenta del risultato, (e vorrei anche vedere, ne sta vendendo a pacchi. I NAS Zyxel, WD, Pogoplug, Seagate, Dlink, e vari altri sono tutti dei SoC kirkwood e sono tutti hackerabili per farci girare su Debian o Arch linux).
Pensa che hanno messo open anche il successore, l'Armada 370 e pure l'XP e donato dev board con Armada XP (roba potente, un SoC da server) al progetto Debian ARM per assistere nello sviluppo e compilazione dei pacchetti.
https://www.debian.org/News/2015/20150108

e sia per le differenti interfacce con i bootloader.Questo è un problema del bootloader. Se non è possibile piallarlo e metterci un Uboot decente, si aggiunge un altro bootloader che si finge il firmware che il bootloader fa partire, ma che in realtà avvia un terzo bootloader (Uboot) che poi gestisce l'avvio di Linux.
Se il bootloader è bloccato (i.e. si aspetta dei kernel firmati da chiavi crittografiche che solo chi ha fatto il dispositivo possiede) c'è poco da fare.

Altrimenti ad esempio sarebbe banale fare una build di Android valida per tutti gli ARMv7 che si tira dietro tutti i moduli kernel necessari.Guarda che tecnicamente sarebbe già così se i driver fossero open e in mainline (nel kernel), il problema sono i blob proprietari e/o le librerie che devono essere ricompilati nel/col kernel per far funzionare ogni singola baracca. E parlo di GPU e accelerazione hardware, ma anche wifi, bluetooth o NFC o radio integrata.

Chi fa le ROM custom piglia il sorgente Cyanogen o AOSP o da dove gli pare, picchia due o tre file di configurazione, infila i blob proprietari necessari (se l'OEM è stato così carino da ottemperare alla GPL e fornirli insieme al sorgente del kernel) e bum, fa la magia.
Poi passa settimane a ricnorrere i vari problemi di configurazione dei blob proprietari che richiedono l'utilizzo di formule magiche arcane nei file di configurazione specifici.

prova ad indovinare perchè i dispositivi che restano bloccati ad una certa versione di Android anche nelle rom custom non possono essere aggiornati?
Esatto, i blob proprietari del menga girano male o non girano proprio con kernel più nuovi! Ilarità!

Ci sono coraggiosi hacker che a colpi di reverse-engineering stanno creando tali driver open, i driver sono: freedreno per le Adreno, lima e tamil per le Mali, non so per i Tegra.
In teoria i Videocore di Broadcom sono open ora.

Strano ma vero, Broadcom sta contribuendo a freedreno per supportare le gpu più nuove http://www.phoronix.com/scan.php?page=news_item&px=MTgyNzM
Notare come lo sviluppatore sia stato assunto da Red Hat, che ha chiaramente interesse alla cosa. Non mi sorprende. Sarebbe figo poter avere una alternativa ad Intel, così per evitare che si senta troppo padrona del campo.

E ancora, a Broadcom hanno assunto un tizio serio per sviluppare i driver open per il raspi e il videocore in generale https://www.phoronix.com/scan.php?page=news_item&px=MTcyMTc
Ed è questo qui (con assistenza dalla community) che sta portando i driver open al livello di qualità sufficiente per entrare in mainline (nel kernel), e ci sta per entrare http://www.phoronix.com/scan.php?page=news_item&px=Raspberry-Pi-VC4-Linux-4.0

Magari hanno capito l'antifona dopo l'esperienza col raspi (che anche se era un SoC scarso con limitazioni orride ha venduto uno sproposito e continua a stravendere tanto che Broadcom ha fatto un SoC custom solo per loro per poter fare il raspi 2 quadcore senza cambiare le schede e quindi continuare a stravendere brutalmente)? Sarebbe bello eh.

Bello. :)
Non sai quanto mi infastidisca vedere gente che prende una dev board, la mette in una scatolina e la usa per fare cose dove le prende di brutto da dispositivi che costano 20-30 euro in più.


Potrei dire la stessa cosa al contrario: avere hardware eccessivo per un lavoro che può essere fatto da hardware più economico, facilmente reperibile e sostituibile. Pensare di costruire un business attorno ad una board che oggi esiste e domani non esiste più significa fare un salto nel vuoto. Per questo gli rpi2 sono identici agli rpi1 eccetto per la cpu quad core.

E comunque ripeto: dispositivi che costano 20-30 euro in più sono giocattoli INUTILI se non c'è un adeguato supporto, cosa che i chip cinesi per esempio non offrono.


Sei atipico (in senso buono eh), in genere chi fa roba embedded fa cose usa-e-getta. Non dei sistemi dove il sowftware si può aggiornare indipendentemente dall'hardware.
Per fare quello che dici sopra andavano bene un pò tutti i SoC da tablet vari. Certo ti limitano al kernel X e alla libreria Y, ma una volta fatto il firmware chissenefrega e se c'è da fare aggiornamenti che il SDK non ti permette di fare (di solito non è il caso) allora si cambia tutto.

Cosa non possibile nel mio caso. Siamo potuti passare dagli rpi1 agli rpi2 senza fare nessun tipo di convoluzione software, solo aggiornare il kernel.


le specifiche della architettura ARMv6 lasciano facoltativa l'implementazione di una fpu, quindi un binario che si aspetta che ci sia e magari gira su un SoC senza si incastra o se il firmware è decente gira con la decodifica software (quindi di fatto si incastra).
Dalla architettura ARMv7 la fpu è obbligatoria (appunto perchè hanno riconosciuto la cazzata del lasciare la scelta ad un branco di gatti quali sono quelli che fanno i SoC).


http://www.arm.com/products/processors/technologies/vector-floating-point.php

dice che sia VFPv2 che VFPv3 sono facoltative nelle rispettive architetture (ARMv5 e ARMv6 per VFPv2 e ARMv7 per VFPv3).
Il firmware poi non c'entra nulla in questo discorso. Da che mondo è mondo, se una istruzione non è supportata dalla CPU, questa genera un interrupt. L'interrupt viene catturato dal sistema operativo. Quello che accade con le softfpu è che il sistema operativo emula una fpu eseguendo tali istruzioni, oppure termina il processo se la softfpu non è prevista.
L'altra strada, più performante, è quella di compilare direttamente i sorgenti per usare una softfpu, senza passare per il kernel che rende il tutto più lento.


Quello che stai dicendo non ha senso comunque, il raspi 1 ha un ARMv6, il raspi 2 ha un ARMv7.
ARMv7 è retro-compatibile con ARMv6 per ovvie ragioni.
Cioè per dire posso far girare dei binari compilati sul mio NAS zyxel (ARMv5) dentro al mio smartphone (ARMv7 sicuramente perchè ha VFPv3 e NEON, forse ARMv8).

Semmai dici che i firmware scritti per il raspi 1 vanno tranquillamente sul raspi 2. Ma quello è solo perchè il processore ARM in quel SoC è secondario rispetto alla GPU, che è la "CPU" del SoC a livello hardware, quindi a parte il far girare codice compilato per ARMv6 su un ARMv7 il resto dell'hardware è esattamente lo stesso.


Ha perfettamente senso invece.

Retrocompatibilità totale, praticamente passare da rpi1 a rpi2 è uguale identico al fare un upgrade del processore sulla tua scheda madre: non devi modificare una virgola nel tuo software.
Io penso che alla Raspberry Foundation avrebbero potuto facilmente progettare una nuova board con hardware rinnovato come fanno tutti gli altri, ma non lo hanno fatto per garantire la retrocompatibilità. Tutti i progetti già esistenti continuano a funzionare.

La questione firmware ancora non la capisco... forse è l'unica cosa che deve essere leggermente modificata per accomodare la presenza di più core, assieme al kernel del sistema operativo.


Licenza di usare il SDK.
Poi certo è un ammasso di script di compilazione merdacchiosi con blob (quando va bene) o kernel precompilati da dio solo sa chi e come, con un blob unico che contiene TUTTO e tu puoi fare solo dei ricamini ai bordi o cambiare le icone.
Ma dipende da quello che vuoi farci.


Concordo.
Preferisco avere kernel mainline che volendo posso ricompilare a mio piacere, invece di blobboni precomipilati e bloccati dal produttore che deve programmare l'obsolescenza del suo prodotto.


Sì, perchè nel Raspi a livello hardware la "CPU" è il VideoCore (quella che chiamiamo GPU, perchè è una GPU, ma comunque è un processore)
Gestisce l'hardware mentre la macchina si avvia ed eventualmente inizializza il processore ARM, il processore ARM è un sottoposto, e lo stesso per il firmware/OS del dispositivo.
Volendo potresti far girare il raspi senza inizializzare mai il processore ARM (se hai un firmware che gira sul VideoCore o se lo chiami da fuori come se fosse una GPU dedicata).

Di fatto il Raspi è la bestemmia suprema all'open (e molti lo hanno fatto presente in passato), perchè quello che chiami "bios" non è solo il firmware della GPU (che vabbè, glie li si lascia fare dai) o un bootloader (e anche qui vabbè, va bene dai) è di fatto un hypervisor hardware closed source (quindi non sai cosa fa), perchè è la GPU quella che comanda/controlla l'hardware in quel SoC (ad esempio, la ram usata dal processore ARM è allocata dal MMU del processore ma passa per la MMU controllata dalla GPU).
Quello che gira nella GPU non lo vedi, punto.
Mentre con un BIOS o anche con un blob proprietario tutto gira sulla CPU quindi si può tenere d'occhio facilmente.


Oh, loro dichiarano che start.elf è il firmware:

http://elinux.org/RPi_Advanced_Setup#Setting_up_the_boot_partition

e me pare più che giusto. Tanti dispositivi oggi hanno il firmware che viene caricato dall'esterno, dalle chiavette wifi alle schede video.
Che poi tutto parta dalla GPU che a sua volta inizializza l'ARM non è una novità particolare, l'architettura di quel SoC è fatta così. E anche la MMU è normale che risieda sulla GPU se è la GPU ad avere in seno il controller della memoria.

Secondo me ti sei perso che hanno fatto i FDT per dare queste configurazioni al kernel senza doverlo ricompilare a manina per ogni scheda. http://elinux.org/Device_Tree .

Solo che funziona solo se hai tutte le informazioni necessarie e come hai scritto tu stesso è un casino con tutti i produttori che non hanno ancora capito che è vantaggioso pure per loro fornirle.

"E se il vero prezzo fosse mascherato dalle spese di spedizione?"
Mi è venuto questo sospetto, visto che 9$ mi sembrano decisamente troppo pochi per un single board computer con Wi-Fi, processore AllWinner ecc. e la spedizione sembra costare un po' troppo, rendendolo alla fine costoso per le sue specifiche ($29, se si aggiunge poi il modulo hdmi va molto in alto...)
A questo punto vale la pena di prendere un altro single board computer come Orange Pi 2, della quale sono felice possessore (https://www.board-db.org/detail.php?boardid=49) o Raspberry Pi B+, ora che il prezzo è sceso a soli $25!

"E se il vero prezzo fosse mascherato dalle spese di spedizione?"
Mi è venuto questo sospetto, visto che 9$ mi sembrano decisamente troppo pochi per un single board computer con Wi-Fi, processore AllWinner ecc. e la spedizione sembra costare un po' troppo, rendendolo alla fine costoso per le sue specifiche ($29, se si aggiunge poi il modulo hdmi va molto in alto...)
A questo punto vale la pena di prendere un altro single board computer come Orange Pi 2, della quale sono felice possessore (https://www.board-db.org/detail.php?boardid=49) o Raspberry Pi B+, ora che il prezzo è sceso a soli $25!

Si infatti, questi chip sono un po' una mezza sòla visto cosa offre il mercato...

Pensare di costruire un business attorno ad una board che oggi esiste e domani non esiste più significa fare un salto nel vuoto.Dato che il software gira anche su altre dev board non vedo il problema.
E comunque ripeto: dispositivi che costano 20-30 euro in più sono giocattoli INUTILI se non c'è un adeguato supporto, cosa che i chip cinesi per esempio non offrono.Cosa intendi per "supporto" esattamente?
Cosa non possibile nel mio caso. Siamo potuti passare dagli rpi1 agli rpi2 senza fare nessun tipo di convoluzione software, solo aggiornare il kernel.Completamente inaspettato.
Se cambi il kernel/blob(se ne hai) puoi portare la stessa roba dove ti pare (basta che resti ARM).
Il kernel contiene i driver e tutto Se vambi quello il resto dell'OS lo fai girare dove vuoi.
http://www.arm.com/products/processors/technologies/vector-floating-point.phpdice che sia VFPv2 che VFPv3 sono facoltative nelle rispettive architetture (ARMv5 e ARMv6 per VFPv2 e ARMv7 per VFPv3).Acc, errore mio. :) Confuso con ARMv8, è lì che VFPv4, NEON e altra roba diventano obbligatori, stesse ragioni di cui sopra. https://en.wikipedia.org/wiki/ARM_architecture#64.2F32-bit_architecture

Quello che accade con le softfpu è che il sistema operativo emula una fpu eseguendo tali istruzioni, oppure termina il processo se la softfpu non è prevista.Cioè o si inchioda perchè il processo viene terminato o si inchioda perchè se usava una FPU è codice che sul processore lo impalla.

Ha perfettamente senso invece.
Retrocompatibilità totale, praticamente passare da rpi1 a rpi2 è uguale identico al fare un upgrade del processore sulla tua scheda madre: non devi modificare una virgola nel tuo software.Non hai capito, è ritenere che la retrocompatibilità sia dovuta al SoC che non ha senso.
La retrocompatibilità è dovuta all'architettura ARM che è fatta per essere retrocompatibile, non al SoC in particolare.
Come il x86-64/amd64 (64 bit) che fa girare i binari in x86 (32bit) è uguale al ARMv7 che fa girare tutto quello che gira in CPU ARMv6 o ARMv5.

Qualsiasi cosa giri un un raspi gira anche dentro ad un qualsiasi altro SoC (a parte per i pin GPIO ma è facilmente adattabile), perchè nel 99% dei casi non stai controllando direttamente l'hardware, ma fai chiamate all'OS linux e al kernel che poi si smazzano e controllano l'hardware.

è uno dei motivi per cui sviluppare su un ciappino del genere con dentro un OS linux completo (con o senza interfaccia grafica) è una figata, perchè il software lo adatti facilmente a tutte le piattaforme.

Cioè per dire se ti andasse di comprare una altra board potresti farlo tranquillamente, basta che ci metti su Debian ARM e adatti i programmi che usavano i GPIO (i pin multiuso) ai GPIO del nuovo SoC.

La questione firmware ancora non la capisco... forse è l'unica cosa che deve essere leggermente modificata per accomodare la presenza di più core, assieme al kernel del sistema operativo.No, è praticamente una distro linux specializzata.
Come per tutti i sistemi linux l'unica cosa che cambia quando cambi hardware supportato (entro la stessa architettura) è qualche settaggio nel kernel, e i driver dell'hardware (che se sono open sono nel kernel, sennò sono dei blob).

Preferisco avere kernel mainline che volendo posso ricompilare a mio piacere, invece di blobboni precomipilati e bloccati dal produttore che deve programmare l'obsolescenza del suo prodotto.Beh, dipende dal businness model. Molti produttori di roba embedded preferiscono così, che così i clienti devono comprare roba nuova.

Se tu fai pagare il servizio (chessò un affitto o cose così) allora ti conviene parecchio che sia open perchè così sei tu che controlli tutto.
Personalmente preferisco l'open anche io.

Oh, loro dichiarano che start.elf è il firmware:
http://elinux.org/RPi_Advanced_Setup#Setting_up_the_boot_partition
e me pare più che giusto. Tanti dispositivi oggi hanno il firmware che viene caricato dall'esterno, dalle chiavette wifi alle schede video.Ti ho già detto che quello che NON è normale nè simpatico è che la GPU giri da sola senza che il kernel linux possa controllare il suo operato.
La GPu fa cose prima che la CPU ARM sia persino inizializzata, e continua a girare per i fatti suoi anche dopo usando RAM che è inaccessibile e incontrollabile dal kernel, per far funzionare la scheda.
Se nel firmware della GPU ci fossero dei backdoor o peggio, il kernel linux sarebbe inpotente.

Che poi tutto parta dalla GPU che a sua volta inizializza l'ARM non è una novità particolare, l'architettura di quel SoC è fatta così. E anche la MMU è normale che risieda sulla GPU se è la GPU ad avere in seno il controller della memoria.Ho detto che ci sono due MMU.
In generale nei SoC decenti la GPU e la CPU hanno una MMU ciascuno.
Come nei PC con GPU dedicata e ram dedicata.

Solo che funziona solo se hai tutte le informazioni necessarie e come hai scritto tu stesso è un casino con tutti i produttori che non hanno ancora capito che è vantaggioso pure per loro fornirle.Come se fosse difficile ottenerle (tutti i vari banana Pi, Cubietruck, Oluxino Marsboard, eccetera sono Allwinner e usano il FDT eh).
Il problema non è il FDT, il problema sono i driver proprietari.

Come se fosse difficile ottenerle (tutti i vari banana Pi, Cubietruck, Oluxino Marsboard, eccetera sono Allwinner e usano il FDT eh).
Il problema non è il FDT, il problema sono i driver proprietari.

In quei casi hai il produttore dell'hardware finale che fornisce le informazioni
necessarie, in tutti gli altri casi no, al massimo si può tentare a colpi di reverse engineering ecc.
Come dicevo, persino con lo stesso SoC è un casino perche ad esempio il bootloader di secondo livello degli Allwinner rimappa i GPIO e le linee dedicate ad I2C ecc. ecc.
ma non ha informazioni riguardo quello che ci viene collegato (quelle le ha il kernel Linux compilato ad hoc con l'SDK degli Allwinner).

La tua soluzione è un stadio aggiuntivo di boot (un "boot loader standard") che risolva tutto, solo che se non è già installato dal produttore e con le informazioni corrette, ci si ritrova nuovamente nella situazione attuale.

Dato che il software gira anche su altre dev board non vedo il problema.


Hello world ci gira sicuramente. Non altrettanto sicuramente ci gira software che, come dici tu dopo, interagisce con il GPIO, che usa componenti OpenMAX per la decodifica hardware, che usa OpenVG/OpenGL per la grafica 2D/3D, etc... etc...

Nel mio particolarissimo caso, siccome il videocore IV ha un compositor hardware, io lo uso con una certa efficacia. Altri SoC il compositor hardware non ce l'hanno o non lo espongono, quindi mi attaccherei al tram.


Cosa intendi per "supporto" esattamente?


Accesso ai sorgenti, accesso alla documentazione, disponibilità dei programmatori e sviluppatori dei driver/kernel ad ascoltare i problemi e bug fixing.


Se cambi il kernel/blob(se ne hai) puoi portare la stessa roba dove ti pare (basta che resti ARM).
Il kernel contiene i driver e tutto Se vambi quello il resto dell'OS lo fai girare dove vuoi.


Nel mondo ideale certamente. Nel mondo attuale non ancora purtroppo.
Mi viene in mente il caso di una famosa App mediaplayer su android che ti fa' scaricare da parte un pacchetto di Codec specifico per il produttore del SoC. Se fosse tutto uniforme non avresti problemi ad usare i componenti OpenMAX per tutte le decodifiche di file multimediali... il problema è che ogni produttore di SoC fa' di testa sua. I cinesi sono i peggiori di tutti, ovviamente, i quali o hanno componenti che non seguono le specifiche (tipo alcuni vecchi Rockchip) oppure non ce li hanno proprio i componenti OpenMAX (Allwinner, che obbliga ad usare i suoi blob proprietari).


Acc, errore mio. :) Confuso con ARMv8, è lì che VFPv4, NEON e altra roba diventano obbligatori, stesse ragioni di cui sopra. https://en.wikipedia.org/wiki/ARM_architecture#64.2F32-bit_architecture

Cioè o si inchioda perchè il processo viene terminato o si inchioda perchè se usava una FPU è codice che sul processore lo impalla.


Non si inchioda se è previsto che il kernel catturi l'eccezione e il codice viene delegato alla softfpu.
Una tecnica simile si usava con windows 95/98 per accedere alle porte di I/O da parte dei programmi DOS che, in modalità virtual 8086 non avrebbero potuto farlo.


Non hai capito, è ritenere che la retrocompatibilità sia dovuta al SoC che non ha senso.
La retrocompatibilità è dovuta all'architettura ARM che è fatta per essere retrocompatibile, non al SoC in particolare.
Come il x86-64/amd64 (64 bit) che fa girare i binari in x86 (32bit) è uguale al ARMv7 che fa girare tutto quello che gira in CPU ARMv6 o ARMv5.


Ma io parlo di retrocompatibilità dell'intera piattaforma. Forse prima non s'era capito.


Qualsiasi cosa giri un un raspi gira anche dentro ad un qualsiasi altro SoC (a parte per i pin GPIO ma è facilmente adattabile), perchè nel 99% dei casi non stai controllando direttamente l'hardware, ma fai chiamate all'OS linux e al kernel che poi si smazzano e controllano l'hardware.


Vedi i casi particolari di accesso alle periferiche di cui sopra. E' ovvio che ARMv7 è ARMv7 per tutti, così come x86 è x86 per tutti.
In un caso reale di porting ci sarebbe un 90/95% di codice che gira tale e quale fra le varie implementazioni ARMv7, ma il restante 5/10% sarebbe rognosamente lì a richiedere sviluppo per essere portato su un diverso SoC.


Beh, dipende dal businness model. Molti produttori di roba embedded preferiscono così, che così i clienti devono comprare roba nuova.

Alché il cliente sveglio potrebbe dire: "Mi hai fregato oggi, non mi freghi più domani". Poi comunque c'è sempre il contesto da valutare, avanzamento tecnologico in primis.


Ti ho già detto che quello che NON è normale nè simpatico è che la GPU giri da sola senza che il kernel linux possa controllare il suo operato.
La GPu fa cose prima che la CPU ARM sia persino inizializzata, e continua a girare per i fatti suoi anche dopo usando RAM che è inaccessibile e incontrollabile dal kernel, per far funzionare la scheda.
Se nel firmware della GPU ci fossero dei backdoor o peggio, il kernel linux sarebbe inpotente.


Beh si è la sua architettura. Purtroppo non ci si può fare niente tranne che fidarsi, oppure avere un firmware open, che sarebbe l'ideale.
Comunque se si volesse affrontare la questione, questa sarebbe infinita perché ad ogni livello puoi avere del codice che il kernel non può gestire. Uno dovrebbe indispettirsi per qualsiasi firmware proprietario giri nel proprio computer, specialmente quello delle schede di rete e wifi.
Sfortunatamente i produttori di hardware hanno i loro "segreti" e i loro brevetti da proteggere, quindi si deve scendere ad un inevitabile compromesso.

Hello world ci gira sicuramente. Non altrettanto sicuramente ci gira software che, come dici tu dopo, interagisce con il GPIO, che usa componenti OpenMAX per la decodifica hardware, che usa OpenVG/OpenGL per la grafica 2D/3D, etc... etc...OpenMAX è il backend del Kernel linux per la decodifica hardware.

Open<qualcosa> sono di nuovo delle API standard del sistema grafico del kernel, che fa gestire al driver, proprietario o no.

Nel mio particolarissimo caso, siccome il videocore IV ha un compositor hardware, io lo uso con una certa efficacia. Altri SoC il compositor hardware non ce l'hanno o non lo espongono, quindi mi attaccherei al tram.Se si parla di SoC con processori che non fanno schifo come quello del raspi1 ci metti Openbox (che gira su CPU) e va bene lo stesso.

Se usavi Wayland per l'interfaccia (che poi smolla al compositor hardware nel caso del raspi, ma è una questione che a te non importerebbe) sarebbe stato meglio per rendere più portabile il software.
http://ppaalanen.blogspot.fi/2013/05/weston-on-raspberry-pi-accelerated.html
https://www.raspberrypi.org/preview-the-upcoming-maynard-desktop/

Se fai roba tu manualmente leghi il programma all'hardware, quindi raspi1-2 non è un caso di compatibilità dei binari.
E' un caso che l'hardware è esattamente lo stesso a parte il processore e tu ti sei furbescamente interfacciato direttamente con l'hardware invece che passare dall'OS.

Accesso ai sorgenti, accesso alla documentazione, disponibilità dei programmatori e sviluppatori dei driver/kernel ad ascoltare i problemi e bug fixing.Dei sorgenti cosa te ne fai esattamente?
La documentazione c'è anche per gli altri, se devi fare una roba che poi leghi all'hardware come hai fatto che ti frega che funga con o senza blob?

per i bug concordo. Almeno rispondono.

Mi viene in mente il caso di una famosa App mediaplayer su android che ti fa' scaricare da parte un pacchetto di Codec specifico per il produttore del SoC.I codec da che mondo e mondo sono istruzioni per fare la decodifica su CPU.
MX Player fa scaricare i codec per ARMv6 o ARMv7 con NEON o senza NEON eccetera.

Se devi usare quelli stai bypassando l'accelerazione hardware del dispositivo e usando il processore o le istruzioni aggiuntive NEON (specifiche per roba multimediale)

Se fosse tutto uniforme non avresti problemi ad usare i componenti OpenMAX per tutte le decodifiche di file multimediali... il problema è che ogni produttore di SoC fa' di testa sua. Per Android salvo Allwinner e Mediatek e forse qualche altro scarso se la cavano comunque bene perchè almeno si sono messi d'accordo.

Su linux eh, NEON, NEON e ancora NEON in attesa che saltino fuori i driver open.
ARM nella sua infinita saggezza ha persino messo le istruzioni NEON obbligatorie negli ARMv8 (perchè OpenMAX va a battere su NEON in mancanza d'altro).
NEON è comune anche negli ARMv7, tra cui il raspi2.
Consiglio caldamente di usarlo o di usare programmi che lo sfruttano.

Non si inchioda se è previsto che il kernel catturi l'eccezione e il codice viene delegato alla softfpu.Se un programma si aspetta di avere accesso ad una FPU e gli dai una softfpu in genere le performance scendono tanto. "si inchioda" è un eufemismo per dire che lagga così tanto che non ha senso usarlo.

Ma io parlo di retrocompatibilità dell'intera piattaforma. Forse prima non s'era capito.Se tu parli di binari io capisco binari in generale.
Se tu mi dici che hai fatto dei binari col tuo programma che di fatto funzionano solo con lo stesso identico hardware del raspi allora il problema è del tuo binario, e per estensione tuo.

Cioè è come dire che hai sviluppato un software per PC che sfrutta il driver delle schede AMD e basta, poi dire che le schede AMD sono retrocompatibili. :mbe:
Ma usa i framework dell'OS, cosa ci sono da fare secondo te?

Alché il cliente sveglio potrebbe dire: "Mi hai fregato oggi, non mi freghi più domani".Problema risolto a monte. Son tutti così. E vale anche per gli elettrodomestici.

Ah a proposito, se sviluppi una lavatrice comandata da un raspi e con una interfaccia da essere umano che permette di settare i tempi, i litri, i giri eccetera del lavaggio dimmi qualcosa.

questa sarebbe infinita perché ad ogni livello puoi avere del codice che il kernel non può gestire. Uno dovrebbe indispettirsi per qualsiasi firmware proprietario giri nel proprio computer, specialmente quello delle schede di rete e wifi.Sto ripetendo da 3 post che qui il problema non è il firmware, il problema è che la GPU gira per i fatti suoi ed è la GPU che controlla il SoC tramite questo firmware che il kernel non vede neanche passare nè girare perchè gira nella ram dedicata alla GPU.

Quindi il kernel linux è solo un passeggero.

Se fosse solo il firmware della GPU, caricato dal kernel e non controllasse tutto l'hardware del SoC andrebbe anche bene.

OpenMAX è il backend del Kernel linux per la decodifica hardware.

Open<qualcosa> sono di nuovo delle API standard del sistema grafico del kernel, che fa gestire al driver, proprietario o no.


Veramente, no. Open<qualcosa> sono le specifiche del Khronos Group. Le implementazioni sono totalmente userland, quindi il kernel non c'entra.
OpenMAX non è la decodifica hardware, ma sono componenti standard per la multimedialità, fra cui la decodifica hardware dei flussi audio/video/immagini, ma anche la codifica (la GPU del raspberry può fare encoding h264 a 1080p a 30fps, in teoria).


Se si parla di SoC con processori che non fanno schifo come quello del raspi1 ci metti Openbox (che gira su CPU) e va bene lo stesso.


Forse non ci siamo ben capiti... io smollo quasi del tutto la riproduzione di flussi 720p all'hardware della GPU. Grossomodo con un 15% di uso della CPU riproduco flussi a 12-14 Mbps.
Un 10% risicato è utilizzato da processi grafici che mostrano cose a video.
Per la rimanente parte l'ARM si ruota i pollici, tranne quando c'è qualche video da tirare giù da internet. Lì subentrano OpenVPN (soprattutto) e LUKS a fagocitare la parte quello che rimane della CPU, più i processi del kernel.
OpenBOX non mi serve, non è un mediaplayer.


Se usavi Wayland per l'interfaccia (che poi smolla al compositor hardware nel caso del raspi, ma è una questione che a te non importerebbe) sarebbe stato meglio per rendere più portabile il software.
http://ppaalanen.blogspot.fi/2013/05/weston-on-raspberry-pi-accelerated.html
https://www.raspberrypi.org/preview-the-upcoming-maynard-desktop/

Se fai roba tu manualmente leghi il programma all'hardware, quindi raspi1-2 non è un caso di compatibilità dei binari.
E' un caso che l'hardware è esattamente lo stesso a parte il processore e tu ti sei furbescamente interfacciato direttamente con l'hardware invece che passare dall'OS.


Wayland non ancora proponibile per un ambiente di produzione e la portabilità è in secondo piano.
Non sono "furbescamente interfacciato" con l'hardware, non ho scritto driver del kernel io. Utilizzo normalmente OpenVG, OpenMAX, etc... ma anche strumenti come il compositor, che ha un'api proprietaria perché non esiste un'api di riferimento. E anche i componenti standard hanno sempre qualche differenza fra questo e quel produttore.


Dei sorgenti cosa te ne fai esattamente?
La documentazione c'è anche per gli altri, se devi fare una roba che poi leghi all'hardware come hai fatto che ti frega che funga con o senza blob?


Perché se mi serve fare debug, posso guardare cosa accade nei sorgenti (capitato: scovato un bug importante, chiesto di correggerlo sul forum e me lo hanno corretto).
La documentazione è essenziale se vuoi farci girare qualcosa più di campo minato. Se non ti dicono come funziona un componente OMX, oppure il compositor hardware, non li puoi usare.


I codec da che mondo e mondo sono istruzioni per fare la decodifica su CPU.
MX Player fa scaricare i codec per ARMv6 o ARMv7 con NEON o senza NEON eccetera.

Se devi usare quelli stai bypassando l'accelerazione hardware del dispositivo e usando il processore o le istruzioni aggiuntive NEON (specifiche per roba multimediale)


MX Player, se non ricordo male, ti fa' scegliere se vuoi decodifca software, hardware oppure hardware+ (mi pare si chiami così). Ho un tablet HP schifoso con SoC rockchip, con decodifica h264 in hardware, frizzi e lazzi, e ovviamente la decodifica HW non si può usare perché è buggata.


Per Android salvo Allwinner e Mediatek e forse qualche altro scarso se la cavano comunque bene perchè almeno si sono messi d'accordo.


Tolti allwinner e Mediatek hai tolto il 90% dei chip cinesi dal gioco.


Su linux eh, NEON, NEON e ancora NEON in attesa che saltino fuori i driver open.
ARM nella sua infinita saggezza ha persino messo le istruzioni NEON obbligatorie negli ARMv8 (perchè OpenMAX va a battere su NEON in mancanza d'altro).
NEON è comune anche negli ARMv7, tra cui il raspi2.
Consiglio caldamente di usarlo o di usare programmi che lo sfruttano.

E' ovvio che se ci sono le NEON, è bene usarle.
Ma se hai hardware dedicato per fare un compito è ancora meglio usare quell'hardware dedicato.


Se un programma si aspetta di avere accesso ad una FPU e gli dai una softfpu in genere le performance scendono tanto. "si inchioda" è un eufemismo per dire che lagga così tanto che non ha senso usarlo.


Ha senso usarlo se la differenza fra le due opzioni è che senza softfpu non funziona, con softfpu funziona. Poi se sarà lento come un bradipo narcolettico sarà un altro problema.


Se tu parli di binari io capisco binari in generale.
Se tu mi dici che hai fatto dei binari col tuo programma che di fatto funzionano solo con lo stesso identico hardware del raspi allora il problema è del tuo binario, e per estensione tuo.

Cioè è come dire che hai sviluppato un software per PC che sfrutta il driver delle schede AMD e basta, poi dire che le schede AMD sono retrocompatibili. :mbe:
Ma usa i framework dell'OS, cosa ci sono da fare secondo te?


Infatti io uso le librerie grafiche. Ma come immagino ben saprai, in ambito ludico anche se usi se le stesse librerie grafiche (DX, OpenGL), non sempre il risultato è lo stesso se cambi hardware che comunque supporta entrambe le librerie.
OpenMAX (o meglio, le sue implementazioni) è estremamente sensibile sotto questo aspetto. E poi, un altro produttore mi garantisce riproduzione fluida a 50fps dei miei filmati 720p a 12-14 Mbps? Il compositor hardware, come dicevo in precedenza, non credo sia molto comune e me ne dovrei programmare io uno software per i miei scopi. Altro tempo speso...


Sto ripetendo da 3 post che qui il problema non è il firmware, il problema è che la GPU gira per i fatti suoi ed è la GPU che controlla il SoC tramite questo firmware che il kernel non vede neanche passare nè girare perchè gira nella ram dedicata alla GPU.

Quindi il kernel linux è solo un passeggero.

Se fosse solo il firmware della GPU, caricato dal kernel e non controllasse tutto l'hardware del SoC andrebbe anche bene.

Si ho capito quello che dici. Il fatto è dal mio punto di vista è una presa di posizione inutile, perché bene o male tutto l'hardware moderno è fatto in questo modo.

ha la stessa ram del mio telefono,un s3 va meglio

spiegatemi come funziona sto kickstarter. loro chiedono 50000$ e ne ricevono 630000$. le domande sono due:
1) i soldi in eccesso che fine fanno
2) perche la gente, una volta che hanno visto che il target di 50000$ è stato raggiunto, continuano a mandare soldi???

Funziona cosi': loro ti danno un goal. Tutti i soldi dal "goal" in poi sono intascati. Salvo qualche percentuale che si tiene il sito, giustamente.
Sei protetto se il progetto non raggiunge la cifra, se la raggiunge puoi fare il culo ai gestori del progetto e dovresti riavere i soldi (non saprei dirti non ho fatto molte "offerte").

La gente continua a mandare soldi per svariati motivi: traguardi aggiuntivi, in cui ti promettono che "se raggiunge 70.000 (parto dal tuo esempio dei 50.000) diamo in regalo anche questi accessori (a chi ha gia' acquistato e chi acquistera', allo stesso prezzo)", e cosi' via. Oppure possono anche non fare traguardi.
Altro motivo e' sempre piu' gente interessata, una volta che il progetto e' stato finanziato e parte, la pubblicita' aumenta. E piu' persone sono interessate. Contando anche che, essendo gia' stato finanziato, e' come se tu comprassi online direttamente, facendo il preorder. Ovvio che prima acquisti e meno ti costa il prodotto, all'inizio devono attirare gente e guadagnarci poco, poi possono sparare i prezzi sempre piu' alti per arrivare a quello finale. I famosi "early bid".

L'unica incognita e' la consegna, piu' richieste hanno e piu' vanno in la' con le spedizioni, a me arrivera' roba entro l'estate 2016 di cose comprate qualche settimana fa.

Veramente, no. Open<qualcosa> sono le specifiche del Khronos Group. Le implementazioni sono totalmente userland, quindi il kernel non c'entra.Open<qualcosa> son le API che devono essere standard sennò non possono dire di essere X. Come vengano gestite dal blob o dal kernel non ha importanza.

OpenMAX non è la decodifica hardware, ma sono componenti standard per la multimedialità, fra cui la decodifica hardware dei flussi audio/video/immagini, ma anche la codifica (la GPU del raspberry può fare encoding h264 a 1080p a 30fps, in teoria).Sì, è il backend di accelerazione hardware. Poi si occupa lui di parlare ai vari sottosistemi hardware.

Openbox non mi serve, non è un mediaplayer.Stavi parlando di interfaccia grafica? Openbox è un window manager, componente fondamentale dell'interfaccia grafica.
https://en.wikipedia.org/wiki/Openbox

Wayland non ancora proponibile per un ambiente di produzione e la portabilità è in secondo piano.Abbeh, eprchè il resto dell'OS di Raspbian è da produzione invece.

Comunque così la differenza rispetto ad un sistema proprietario è 0.
Non paghi il SDK e hai il supporto a gratis.
Se questo è l'"open source" secondo te, allora lasciatelo dire... avere le cose aggratis non è la ragione dell'open source.

Non sono "furbescamente interfacciato" con l'hardware, non ho scritto driver del kernel io. Utilizzo normalmente OpenVG, OpenMAX, etc... ma anche strumenti come il compositor, che ha un'api proprietaria perché non esiste un'api di riferimento. E anche i componenti standard hanno sempre qualche differenza fra questo e quel produttore.Se parli ai driver direttamente sì, sei interfacciato con l'hardware.
Questione di portabilità. Questo è l'open source. Sistemi modulari, non legati all'hardware.
Il Raspi sta iniziando ad essere open quast'anno, forse.

La documentazione è essenziale se vuoi farci girare qualcosa più di campo minato. Se non ti dicono come funziona un componente OMX, oppure il compositor hardware, non li puoi usare.Questa c'è negli SDK eh.

MX Player, se non ricordo male, ti fa' scegliere se vuoi decodifca software, hardware oppure hardware+ (mi pare si chiami così). Ho un tablet HP schifoso con SoC rockchip, con decodifica h264 in hardware, frizzi e lazzi, e ovviamente la decodifica HW non si può usare perché è buggata.Guarda bene che come app accessorie dallo stesso autore ci sono anche i codec.
Tolti allwinner e Mediatek hai tolto il 90% dei chip cinesi dal gioco.Sì magari. Rockchip, Amlogic (più mediacenter).
E' ovvio che se ci sono le NEON, è bene usarle.
Ma se hai hardware dedicato per fare un compito è ancora meglio usare quell'hardware dedicato.Se non vuoi legarti all'hardware, no. Si usano framework, se non ci sono e ci sono soolo i driver (blob o open che siano), stai facendo una cosa per quella macchina lì e basta.

Ha senso usarlo se la differenza fra le due opzioni è che senza softfpu non funziona, con softfpu funziona. Poi se sarà lento come un bradipo narcolettico sarà un altro problema.Se devi far girare un software, deve girare. Che "giri" in teoria ma non va nulla nella realtà non mi importa. O va come dovrebbe andare o non sta andando.

Infatti io uso le librerie grafiche. Ma come immagino ben saprai, in ambito ludico anche se usi se le stesse librerie grafiche (DX, OpenGL), non sempre il risultato è lo stesso se cambi hardware che comunque supporta entrambe le librerie.Perchè i driver e l'hardware sono diversi. Ma le API sono uguali. Sennò che cavolo ci sono da fare?

OpenMAX (o meglio, le sue implementazioni) è estremamente sensibile sotto questo aspetto. E poi, un altro produttore mi garantisce riproduzione fluida a 50fps dei miei filmati 720p a 12-14 Mbps?OpenMAX è lo stesso. Semmai sono i produttori dei SoC che non lo usano coi loro blob.
Visto che tanto ti interfacci direttamente all'hardware comunque... un pò tutti visto che o usi i blob o usi dei driver open. Ovviamente non portabile.

Il compositor hardware, come dicevo in precedenza, non credo sia molto comune e me ne dovrei programmare io uno software per i miei scopi. Altro tempo speso...
Openbox? Scarica sui driver video se disponibili o sul processore.
https://en.wikipedia.org/wiki/Openbox

A mettere su una iterfaccia ci metti 10 secondi e gira ovunque.

Si ho capito quello che dici. Il fatto è dal mio punto di vista è una presa di posizione inutile, perché bene o male tutto l'hardware moderno è fatto in questo modo.Sì, sto solo dicendo che tu hai idee confuse sull'"open source".

Se fai una cosa uguale a quella che fa un dev qualsiasi con un SDK pagato con una dev board chiusa (è aperta solo dall'anno scorso, in parte) qual'è la differenza? Che non paghi e ti fanno supporto a gratis?
Bella la vita eh?

spiegatemi come funziona sto kickstarter. loro chiedono 50000$ e ne ricevono 630000$. le domande sono due:
1) i soldi in eccesso che fine fanno
2) perche la gente, una volta che hanno visto che il target di 50000$ è stato raggiunto, continuano a mandare soldi???
Perchè è reward based.
Spesso, o sempre, hai diritto al prodotto finito pertanto è chiaro che magari quel prodotto lo vuole più gente del minimo che gli serve per cominciare a produrlo.