Newsgroup: it.comp.os.linux.sys
Titolo: Re: Perche android non puo' essere una distribuzione generica come linux sui sistemi x86..

> E no, i SOC NON hanno per niente le stesse specifiche. Hanno in comune solo quelle generali del processore. E spesso nemmeno quelle.
 
Dici che un A10 o un A13 o un wm8650 o un mmkt6577  non sono la stessa cosa ? Alla fine sono una decina di piattaforme al massimo 
(tra table e cellulari).
 
Giulia
 
 


Non sono MINIMAMENTE la stessa cosa.
Il vero problema � il kernal, non il resto del software di sistema.
 
-- 
"Non ho paura degli urli dei violenti, ma del silenzio degli onesti"
Martin Luther King.
 
"La religione � il singhiozzo di una creatura oppressa, il sentimento
di un mondo senza cuore, lo spirito di una condizione priva di spirito.
� l'oppio dei popoli." K. Marx
 
"Nessuna buona azione rimarr� impunita!" (autore sconosciuto, ma SAGGIO!)

 Il vero problema ï¿œ il kernal, non il resto del software di sistema.
 
Ma perche' linux non ce l'ha il HAL come windows?
 
 

 Il vero problema � il kernal, non il resto del software di sistema.
Infatti , ma non riesco a capire quale parte non si riesce ad adattare.
 
Giulia
 
 
 


 
Spero TAAAAAANTO che sia una battuta ....



 
Perch� non conosci come funziona linux come sistema operativo.
Sarebbe da studiare prima quello.
Conoscendo linux Android diventa molto pi� semplice da capire.....


 Spero TAAAAAANTO che sia una battuta ....
 
NO, non lo e'. Ce l'ha o non ce l'ha?
 
 

 Conoscendo linux Android diventa molto più semplice da capire.....
 
Linux android ?
 
Giulia
 
 


 
Si, ma sono SO basati su filosofie diverse.
Linux è un monolitico, mentre Windows è un ibrido.
Leggi qui 
http://it.wikipedia.org/wiki/Kernel
 
 
-- 
"Non ho paura degli urli dei violenti, ma del silenzio degli onesti"
Martin Luther King.
 
"La religione è il singhiozzo di una creatura oppressa, il sentimento
di un mondo senza cuore, lo spirito di una condizione priva di spirito.
È l'oppio dei popoli." K. Marx
 
"Nessuna buona azione rimarrà impunita!" (autore sconosciuto, ma SAGGIO!)


Si. Però hai il problema dell'efficienza. Arm è declinato in molte varianti.
Se ci fosse interesse probabilmente si potrebbe fare una base comune.
Anche un ambiente di sviluppo comune.
Ma non pare che ci sia l'interesse, ovviamente, per questioni commerciali.
Perfino progetti come Cyanogen si fermano davanti alla massa 
dell'hardware disponibile, e supportano solo determinati SOC (da cui poi 
alcuni appassionati derivano altre versioni, mase,pre per quei SOC).
Per farti un esempio i SOC MTK6577, che sono arm7 dualcore di buona 
fattura per quanto economici, e diffusissimi, non hanno nemmeno 
l'ambiente di sviluppo pubblicato.
E questo impedisce di fatto porting di versioni diverse di Android 
rispetto a quelle rilasciate "ufficialmente", per ora ferme alla 4.0.x .
 
-- 
"Non ho paura degli urli dei violenti, ma del silenzio degli onesti"
Martin Luther King.
 
"La religione è il singhiozzo di una creatura oppressa, il sentimento
di un mondo senza cuore, lo spirito di una condizione priva di spirito.
È l'oppio dei popoli." K. Marx
 
"Nessuna buona azione rimarrà impunita!" (autore sconosciuto, ma SAGGIO!)

 Sarebbe da studiare prima quello.
 
Oddio, una ripassata farebbe bene anche a te :)
 
Enrico

 Infatti , ma non riesco a capire quale parte non si riesce ad adattare.
 
Come (all'incirca) ti ho scritto altrove, i sorgenti di AOSP sono da 
quella parte ---> mentre quelli di CyanogenMod (che supporta molte altre 
piattaforme) da quell'altra <---
 
Dai un'occhiata ai repository specifici alle singole piattaforme, (mi 
pare si chiamino android_devices_* oppure devices_*, e vedi tu stesso/a 
le differenze.

 ...ma deve essere device specifica?
 
Riassumendo, per diversi motivi:
 
1- Driver binari.
 
Spesso i SOC usati nei cellulari hanno pezzi non supportati da driver 
open source. I driver binari vengono compilati con una determinata 
versione del kernel, spesso patchato per esporre delle funzionalità al 
particolare driver binario.
Anche mettendo assieme tutti i driver binari di tutti i dispositivi, non 
è detto che funzionino, perché è impossibile avere un kernel che li 
supporti tutti.
 
2- Driver incompatibili
 
Solo di recente è iniziata una unificazione nel kernel tra le varie 
architetture ARM. Ogni produttore, infatti, ha adottato delle piccole 
variazioni rispetto allo "standard ARM" che ha preso come base. Inoltre 
capita (molto raramente) che alcuni dispositivi possano essere "confusi" 
con altri, magari perché hanno id o modi di risposta molto simili.
 
3- Bootloader diversi
 
Non essendoci uno standard vero e proprio per i bootloader, ogni 
produttore di hardware si regola a modo suo. Decide il partizionamento 
della flash interna, piazza il bootloader dove gli pare, può separare o 
meno la partizione dove sta il kernel, ecc. ecc.
Basta vedere le difficoltà che ha avuto la clockwork per adattarsi a 
diversi dispositivi, e come esistano diversi modi per flashare una ROM, 
tipicamente uno o più per ogni produttore di hardware.
 
Bye.

 Linux è un monolitico, 
 
ah! bella cagata.
 
 

Scroto ha scritto:

Non è detto. Ci sono vantaggi e svantaggi ...


 ah! bella cagata.
 
Per me sei un troll, e non capisco perché continuino a risponderti.
 
Bye.
 

Sembra che Alessandro Pellizzari abbia detto :

e con la "qualita'" intrinseca di linux cosa c'entra?
Una cosa e' di suo oggettiva oppure non lo e'.
Qui si parla di linux che e' una cagata.
 
 

Tanto per tirare una linea in maniera molto semplice, vorrei riportare la 
mia esperienza.
Sono un progettista di piattaforme ARM e non solo, da diversi anni ormai.
Posso assicurarvi che nel design di una piattaforma, ci sono veramente 
numerose variabili, che vanno ben oltre ai vari chipset di periferica, ed 
ogni volta, c'� da riscrivere buona parte del kernel affinch� possa ottenere 
il massimo delle prestazioni.
Tanto per fare un esempio molto semplice, nelle mie due ultime versioni 
della medesima scheda (un controller di processi real-time), ho dovuto 
spostare un chip-select da un pin ad un altro per ridurre l'impedenza della 
pista. Stesso soc, stesse periferiche... kernel diverso... e vi assicuro che 
la stessa cosa pu� accadere anche su un pcb di un cellulare.
Il problema del "se" si pu� o meno unificare, sta solo nella volont� o 
nell'interesse di creare un consorzio che imponga a chi voglia aderire, una 
serie di vincoli molto rigidi. La mia personale opinione per� � che in 
questa fase, la ricerca e lo sviluppo di queste piattaforme � ancora molto 
immatura, e si rischierebbe di rallentarne l'evoluzione.
Saluti
 
 

 mia esperienza.
 
Veramente molto interessante, certo si potrebbe sempre immaginare una tabella o una funziona hardware
per astrarre queste modifiche e presentarle in qualche modo al SO, ma come dici servirebbe uno standard.
 
 
Giulia
 
 

 Qui si parla di linux che e' una cagata.
 
Puoi escludere it.comp.os.linux.sys dai tuoi post per cortesia? Non ho
nessuna voglia di leggerli.
 
Grazie
 
	Y.

Scriveva Giulia martedï¿œ, 22/01/2013:

Esattamente quello che fa Windows con l'HAL,
ma linux e' monolitico........
 
 

> Esattamente quello che fa Windows con l'HAL,
 
A che fischio sto HAL , ci sono almeno due strati di software indipendenti dal SO tra l'hardware e l'HAL,
 
http://en.wikipedia.org/wiki/Plug_and_Play_BIOS
 
http://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface
 
 
e oggi e' tutto unificato sotto l'UEFI.
 
Giulia
 
 
 
 

Nel suo scritto precedente, Giulia ha sostenuto :

te ciai confusione in crapa.
non hai capito un cazzo di cosa sia arm
 
 


peccato che ARM non abbia ne il BIOS, ne l'ACPI ne l'UEFI.
 
Ciao Jack
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?


 
Perdonami se mi permetto di correggere leggermente questa affermazione.
In realt� tutti i microcontrollori a bus chiuso o aperto con core ARM (ma 
anche oggetti pi� semplici) hanno la loro versione di BIOS (inteso come 
funzioni elementari di input/output senza standard proprietario).
Magari apparendo in maniera diversa da come gli utenti sono abituati a 
vederlo, potrebbe sembrare del tutto assente, e anche gli addetti tendono a 
non chiamarlo bios, ma c'� ed ha un ruolo fondamentale. Si gestisce in modo 
pi� macchinoso di un bios con UI, magari usando il native boot loader del 
micro o alcuni fuses settabili in programmazione via jtag o simili. La sua 
funzione, come per il bios al quale siamo abituati, � quella di configurare 
il pll, il routing delle periferiche interne e altre funzionalit� utili al 
bootloader (se presente).
Di certo non ha, o ha comunque pochissima conoscenza di periferiche esterne, 
e quindi poco utile per probing.
Saluti 
 
 

 Saluti 
 
quindi, come ho detto, non hanno un BIOS, hanno una routine di
inizializzazione, che negli x86 e' inclusa nel BIOS (ora nella UEFI).


> peccato che ARM non abbia ne il BIOS, ne l'ACPI ne l'UEFI.
 
A si ?
 
While Windows RT incorporates changes to the Windows codebase to provide optimizations for ARM-based devices and their internal hardware, a number of standards 
used by x86 systems are also used as part of its architecture. UEFI is used within Windows RT devices, and a software Trusted Platform Module is used to enable 
device encryption and the ability to prevent unauthorized software from tampering with the boot process.[8] ACPI is also used to detect and control plug and 
play devices and provide power management outside the SoC. To enable wider hardware support, peripherals such as human interface devices, storage and other 
components that use USB and I�C connections utilize class drivers and standardized protocols. Windows Update serves as the primary update mechanism for system 
drivers and software on Windows RT devices.
 
Oltre tutto dal blog microsoft:
 
During Windows 8, we worked to define a new standard to describe the configuration of the system with tables, so software can simply read the table and 
configure the system.
 
http://blogs.msdn.com/b/b8/archive/2012/02/09/building-windows-for-the-arm-processor-architecture.aspx
 
 
L'hal sta almeno 2 livelli software sopra ,anzi i miei complimenti alla microsoft per aver studiato una standardizzazione di basso livello per l'enumerazione e
la inizializzazione dell hardware.
 
Quindi ribadisco , sto HAL che c'azzecca ?
 
Giulia
 
 

 inizializzazione, che negli x86 e' inclusa nel BIOS (ora nella UEFI).
 
...non � esattamente quello che intendevo... ma probabilmente perch� sono 
stato poco chiaro. 
 
 

 architecture. UEFI is used within Windows RT devices, and a software
 
 
si, vai su 
www.arm.com
 scaricati un paio di datasheet e leggiteli.
Ovviamente nessuno vieta di implementare UEFI in un ARM.



 
Per quanto leggere ed imparare sia sempre molto utile e stimolante per 
tutti, consiglierei di partire da livelli un po' pi� concreti.
La tecnologia ARM, rappresenta il core di molti microcontrollori, e sul sito 
www.arm.com
 c'� la descrizione dettagliata del loro funzionamento, ma nella 
realt�, i progettisti usano sistemi integrati dove nello stesso involucro 
c'� il core arm e le periferiche.
Il mio suggerimento � quello di controllare invece uno dei siti dei 
produttori. Per mia esperienza suggerisco 
www.freescale.com
, ma potete 
cercare anche altri.
Ogni ditta nomina i propri processori come meglio crede, ma cita sempre la 
tecnologia ARM quando implementata.
Saluti
 
 

 Qui si parla di linux che e' una cagata.
 
Argomenta, vah, che sono in vena...
 
Enrico

 Linux android ?
 
"Conoscendo Linux VIRGOLA Android diventa molto più semplice da capire..."
 
:-)))
 
 
 
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it