[test] [info] Cyanogen for Odin

ragazzii, ho un quesito di natura tecnica:
si sa che le rom AOSP basate sui sorgenti della cyano (parlo relativamente al galaxy s) hanno una struttura totalmente diversa rispetto alle cosiddette rom stock, sia a livello software sia a livello più profondo (ad esempio la questione della mappa della partizioni diversa, il famigerato pit).

volendo, come per le rom stock-like, esistono gli strumenti per impacchettare il tutto e creare una rom flashabile da odin, e mi chiedo, perchè nessuno l'ha mai fatto?

al di la di quanto possa essere comodo un pacchetto zippabile direttamente da recovery, può avere i suoi svantaggi (per me ad esempio è scomodo perchè son solito formattare completamente la scheda sd prima di eseguire un qualsiasi flash.

ho provato a documentarmi e non ho recupaato materiale che chiarisse i miei dubbi.

la procedura corretta consisterebbe nell'installare una cyano, fare un dump di tutte le partizioni tramite adb, e con un programma come heimdall creare una copia del pit modificato della cyano, impacchettare tutto come .tar
e flashare con repartition flaggato.

a sto punto mi chiedo, esistono delle controindicazioni/ limiti tecnici nel fare questo?

ora che ci penso c'è anche da considerare la questione file system diverso dalla rom stock, ma è davvero un problema?
alla fine odin può flashare anche partizioni in formato diverso da .rfs (come ad esempio le ext4 del galaxy s2)

nessuno ci ha mai pensato perchè non lo riteneva comodo o effettivamente è una cosa sbagliata da fare?

Quote:

---

Originariamente inviato da misha84

ragazzii, ho un quesito di natura tecnica:
si sa che le rom AOSP basate sui sorgenti della cyano (parlo relativamente al galaxy s) hanno una struttura totalmente diversa rispetto alle cosiddette rom stock, sia a livello software sia a livello più profondo (ad esempio la questione della mappa della partizioni diversa, il famigerato pit).

volendo, come per le rom stock-like, esistono gli strumenti per impacchettare il tutto e creare una rom flashabile da odin, e mi chiedo, perchè nessuno l'ha mai fatto?

al di la di quanto possa essere comodo un pacchetto zippabile direttamente da recovery, può avere i suoi svantaggi (per me ad esempio è scomodo perchè son solito formattare completamente la scheda sd prima di eseguire un qualsiasi flash.

ho provato a documentarmi e non ho recupaato materiale che chiarisse i miei dubbi.

la procedura corretta consisterebbe nell'installare una cyano, fare un dump di tutte le partizioni tramite adb, e con un programma come heimdall creare una copia del pit modificato della cyano, impacchettare tutto come .tar
e flashare con repartition flaggato.

a sto punto mi chiedo, esistono delle controindicazioni/ limiti tecnici nel fare questo?

ora che ci penso c'è anche da considerare la questione file system diverso dalla rom stock, ma è davvero un problema?
alla fine odin può flashare anche partizioni in formato diverso da .rfs (come ad esempio le ext4 del galaxy s2)

nessuno ci ha mai pensato perchè non lo riteneva comodo o effettivamente è una cosa sbagliata da fare?

---

Fratello, ti ho sempre seguito in silenzio e con profonda ammirazione: sei un mito!
Questo pensiero che tu hai tramutato in idea mi ha sempre segato il cervello, se non altro perchè so che per il nexus S ESISTE un pacchetto flashabile da Odin con un firmware AOSP! Quindi ritengo lecito che sia possibile farlo anche per altri dispositivi, l'importante è che un pit dia le giuste indicazioni su come settare le partizioni.
Sono sicuro che senza andare lontano, anche usando la guida che postò tempo fa Darky su xda si potrebbe fare un dump del sistema in MTD, mica importa ad Odin o Heimdall cosa contiene il tar?!
La cosa mi intriga parecchio..... Ti seguirò.

Ah una precisazione: è esattamente al contrario, le rom cyano sono basate sui sorgenti AOSP e non viceversa... :)

Quote:

---

Originariamente inviato da umberto1978

Fratello, ti ho sempre seguito in silenzio e con profonda ammirazione: sei un mito!
Questo pensiero che tu hai tramutato in idea mi ha sempre segato il cervello, se non altro perchè so che per il nexus S ESISTE un pacchetto flashabile da Odin con un firmware AOSP! Quindi ritengo lecito che sia possibile farlo anche per altri dispositivi, l'importante è che un pit dia le giuste indicazioni su come settare le partizioni.
Sono sicuro che senza andare lontano, anche usando la guida che postò tempo fa Darky su xda si potrebbe fare un dump del sistema in MTD, mica importa ad Odin o Heimdall cosa contiene il tar?!
La cosa mi intriga parecchio..... Ti seguirò.

Ah una precisazione: è esattamente al contrario, le rom cyano sono basate sui sorgenti AOSP e non viceversa... :)

---

ti informo che sono già a un punto morto: ho provato con heimdall a recuperare la mappa delle partizioni e il risultato è un comune pit 512, perchè i settori e i file associati alle partizioni son sempre gli stessi (tra l'altro mi ha consniderato partizioni rfs, non mtd (anzi, sarebbero dovute essere btd perchè ho fatto un test con l'ultima mintberry con il fs modificato).

appena ho tempo provo a recuperarlo tramite adb, vediamo se la verifica del MD5 evidenzia che sono effettivamente diversi.

tu hai idee da proporre?

ps: io pensavo alle varie cyanofortomorrow, miui e altre che mi sfuggono... si basano sui sorgenti della cyano!

Quote:

---

Originariamente inviato da misha84

ti informo che sono già a un punto morto: ho provato con heimdall a recuperare la mappa delle partizioni e il risultato è un comune pit 512, perchè i settori e i file associati alle partizioni son sempre gli stessi (tra l'altro mi ha consniderato partizioni rfs, non mtd (anzi, sarebbero dovute essere btd perchè ho fatto un test con l'ultima mintberry con il fs modificato).

appena ho tempo provo a recuperarlo tramite adb, vediamo se la verifica del MD5 evidenzia che sono effettivamente diversi.

tu hai idee da proporre?

---

Mmhhh cosi su due piedi no... Suppongo anche che tu abbia gia indagato su xda per vedere se qualchun altro ci ha gia provato.
Mi auguro che con adb cambi il risultato relativamente al pit...
Se nel frattempo scovo qualcosa ti informo;)

Inviato dal mio GT-I9000 usando Tapatalk

Quote:

---

Originariamente inviato da umberto1978

Mmhhh cosi su due piedi no... Suppongo anche che tu abbia gia indagato su xda per vedere se qualchun altro ci ha gia provato.
Mi auguro che con adb cambi il risultato relativamente al pit...
Se nel frattempo scovo qualcosa ti informo;)

Inviato dal mio GT-I9000 usando Tapatalk

---

DOMANDA: quale è il pit??

# su # busybox df -h
Filesystem	Size	Used	Available	Use%	Mounted on
tmpfs	173.8M	32.0K	173.7M	0%	/dev
tmpfs	173.8M	0	173.8M	0%	/mnt/asec
tmpfs	173.8M	0	173.8M	0%	/mnt/obb
/dev/block/mtdblock2	187.5M	142.6M	44.9M	76%	/system
/dev/block/mtdblock3	80.0M	2.3M	77.7M	3%	/cache
/dev/block/mtdblock5	16.0M	14.4M	1.6M	90%	/radio
/dev/block/mmcblk0p2	1.8G	187.2M	1.7G	10%	/data
/dev/block/mtdblock6	172.0M	26.7M	145.3M	16%	/datadata
/dev/block/mtdblock4	12.5M	6.7M	5.8M	54%	/efs
/dev/block/vold/179:1	5.8G	1.3G	4.4G	23%	/mnt/sdcard
/dev/block/vold/179:1	5.8G	1.3G	4.4G	23%	/mnt/secure/asec

una birra a chi ha la risposta

questo invece è il log di heimdall (MintBerry 2.1.20)

codice:

---

Beginning session...
Session begun with device of type: 0

Downloading device's PIT file...
PIT file download sucessful

Entry Count: 13
Unknown 1: 1
Unknown 2: 0
Unknown 3: 7508
Unknown 4: 65
Unknown 5: 64224
Unknown 6: 18
Unknown 7: 55304
Unknown 8: 67


--- Entry #0 ---
Unused: No
Partition Type: 0 (RFS)
Partition Identifier: 0
Partition Flags: 0 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 1
Unknown 2: 6684783
Unknown 3: 2097268
Partition Name: IBL+PBL
Filename: boot.bin


--- Entry #1 ---
Unused: No
Partition Type: 0 (RFS)
Partition Identifier: 1
Partition Flags: 0 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 1
Unknown 2: 0
Unknown 3: 0
Partition Name: PIT
Filename:


--- Entry #2 ---
Unused: No
Partition Type: 0 (RFS)
Partition Identifier: 20
Partition Flags: 2 (R/W)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 40
Unknown 2: 0
Unknown 3: 0
Partition Name: EFS
Filename: efs.rfs


--- Entry #3 ---
Unused: No
Partition Type: 0 (RFS)
Partition Identifier: 3
Partition Flags: 0 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 5
Unknown 2: 0
Unknown 3: 0
Partition Name: SBL
Filename: sbl.bin


--- Entry #4 ---
Unused: No
Partition Type: 0 (RFS)
Partition Identifier: 4
Partition Flags: 0 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 5
Unknown 2: 0
Unknown 3: 0
Partition Name: SBL2
Filename: sbl.bin


--- Entry #5 ---
Unused: No
Partition Type: 0 (RFS)
Partition Identifier: 21
Partition Flags: 2 (R/W)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 20
Unknown 2: 0
Unknown 3: 0
Partition Name: PARAM
Filename: param.lfs


--- Entry #6 ---
Unused: No
Partition Type: 0 (RFS)
Partition Identifier: 6
Partition Flags: 0 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 30
Unknown 2: 0
Unknown 3: 0
Partition Name: KERNEL
Filename: zImage


--- Entry #7 ---
Unused: No
Partition Type: 0 (RFS)
Partition Identifier: 7
Partition Flags: 0 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 30
Unknown 2: 0
Unknown 3: 0
Partition Name: RECOVERY
Filename: zImage


--- Entry #8 ---
Unused: No
Partition Type: 0 (RFS)
Partition Identifier: 22
Partition Flags: 2 (R/W)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 1146
Unknown 2: 0
Unknown 3: 0
Partition Name: FACTORYFS
Filename: factoryfs.rfs


--- Entry #9 ---
Unused: No
Partition Type: 0 (RFS)
Partition Identifier: 23
Partition Flags: 2 (R/W)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 536
Unknown 2: 0
Unknown 3: 0
Partition Name: DBDATAFS
Filename: dbdata.rfs


--- Entry #10 ---
Unused: No
Partition Type: 0 (RFS)
Partition Identifier: 24
Partition Flags: 2 (R/W)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 140
Unknown 2: 0
Unknown 3: 0
Partition Name: CACHE
Filename: cache.rfs


--- Entry #11 ---
Unused: No
Partition Type: 0 (RFS)
Partition Identifier: 11
Partition Flags: 0 (R)
Unknown 1: 0
Partition Block Size: 256
Partition Block Count: 50
Unknown 2: 0
Unknown 3: 0
Partition Name: MODEM
Filename: modem.bin


--- Entry #12 ---
Unused: Yes
Partition Type: 1 (Unknown)
Partition Identifier: 11
Partition Flags: 0 (R)
Unknown 1: 0
Partition Block Size: 0
Partition Block Count: 0
Unknown 2: 0
Unknown 3: 0
Partition Name:
Filename:

Ending session...
Rebooting device...

---

ho provato a scaricare il .pit con heimdall: softbrick!!, un bel BSOD che non mi asettavo sinceramente

Ciao Misha, ho fatto un paio di prove..
Oltre al galaxy s possiedo un galaxy mini (5800) e ieri ho flashato la cyanogen (alpha 7). Il pacchetto era disponibile in estensione tar per essere flashato come un unico file via odin.
Le cose che ho notato sono due: analogamente a quanto avviene per il sgs anche in questo caso esiste una sorta di pit che in questo caso viene chiamato OPS, è un file di pochi KB che ha la stessa funzione del pit. Ebbene questo file è lo stesso che ho usato prima per flashare un firmware samsung e poi per flashare la cyanogen. Ciò significa che il layout delle partizioni è il medesimo sia per rom samsung che per rom AOSP.
Seconda cosa: dopo aver impostato odin (per il flash della cyano) clicco su start e vedo, nel log di odin, che il factoryfs che sta pushando è con estensione RFS. In realtà al riavvio ho una cyanogen perfettamente funzionante.

Ammesso e non concesso che si tratta di un dispositivo che potrebbe non avere nulla a che vedere con il fratello maggiore, noterai anche tu che c'è qualcosa che non torna: all'inizio ho pensato che il file system su cui girava la cyano fosse sempre e comunque in rfs (lo so è una cosa senza senso) ma ovviamente ciò non è possibile, primo perchè l'RFS è un FS proprietario di samsung, secondo perchè il porting è stato eseguito direttamente dai sorgenti cyanogen.

Spero di esserti stato utile.

Ps.: appena metto mano al nexus s di mio nipote flasharò il firmware stock AOSP preparato per ODIN di cui ti parlavo....