Sviluppo e hacking smartphone mediatek

Postate qui per tutte le discussioni legate a Linux in generale.

Moderatore: Staff

Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
rik70
Iper Master
Iper Master
Messaggi: 2207
Iscritto il: gio 10 mar 2011, 9:21
Slackware: 64-current
Kernel: 5.4.x
Desktop: Xfce 4.14
Distribuzione: Arch Linux

Re: Sviluppo e hacking smartphone mediatek

Messaggio da rik70 »

miklos ha scritto: guardando un po' i device tree di altri smartphone ho trovato la formuletta BOARD_KERNEL_PAGESIZE * 64
Esatto: lo script makevendor.sh quando scompatta il boot.img restituisce 'BOARD_PAGE_SIZE 2048' che moltiplicato per 64 fa... =D>

Ok, ci ritorno su questo fine settimana.

Nel frattempo ho tirato giù un paio di sorgenti rilasciati dal produttore dello smartfon. Non sono dell'esatto modello che ho io - ma secondo te se scriviamo per averlo ci ca**no? - ma si vedono delle cose interessanti e il soc è identico: in uno c'è la parte mediatek del config del kernel che gira sul mio hw.

Chiudo con un altra domanda - e ti pareva:
come la genero la parte 'system/vendor/*' visto che non abbiamo "nulla in mano" riguardo al nostro dispositivo?

Sarà mica

Codice: Seleziona tutto

add_lunch_combo cm_<codename>-userdebug
?

ilmich
Master
Master
Messaggi: 1563
Iscritto il: lun 16 lug 2007, 17:39
Slackware: 14.2 64bit
Kernel: 4.19.46
Desktop: dwm
Località: Roma

Re: Sviluppo e hacking smartphone mediatek

Messaggio da ilmich »

rik70 ha scritto:ma secondo te se scriviamo per averlo ci ca**no?
se ti dovessero rispondere mi sa che in ogni caso lo dovresti pagare (o almeno ho vagamente letto una cosa del genere)
rik70 ha scritto:come la genero la parte 'system/vendor/*' visto che non abbiamo "nulla in mano" riguardo al nostro dispositivo?
è per questo motivo che è tutto cosi' complicato.. in teoria alcune cose hanno percorsi specifici e standard (tipo il driver audio e il driver opengl) altre le intuisci dal ramdisk laddove vedi che attiva servizi non 'standard'. Io sono partito da un device tree di un mt6592 trovato su github(ho poi deciso di fare il mio device tree da zero perchè mi sembrava un po' disordinato anche se andrà nei credits semmai finiro il lavoro).
rik70 ha scritto:Sarà mica

Codice: Seleziona tutto
add_lunch_combo cm_<codename>-userdebug

?
quel comando serve ad inizializzare le variabili d'ambiente per la compilazione.

comunque io alla fine ho trovato una rom lollipop che funziona sul mio cubot (ha un po' di bug e il telefono crede di essere un samsung) ma con l'occasione ho spulciato un'altra cosa interessante, ovvero come estrarre e modificare l'immagine logo.bin che contiene le immagini che appaiono all'accensione (tremende nel mio caso) e durante la carica a telefono spento.
L'estrazione avviene sempre tramite i tool mediatek che si usano per esplodere le immagini di boot e della recovery, ho dovuto solo fare una piccola patch che ho sottoposto allo sviluppatore principale perchè non tutte le immagini venivano estratte correttamente
ho visto cose che voi astemi non potete immaginare
https://github.com/ilmich

rik70
Iper Master
Iper Master
Messaggi: 2207
Iscritto il: gio 10 mar 2011, 9:21
Slackware: 64-current
Kernel: 5.4.x
Desktop: Xfce 4.14
Distribuzione: Arch Linux

Re: Sviluppo e hacking smartphone mediatek

Messaggio da rik70 »

Rieccomi dopo un po di tempo con buone nuove - o almeno si spera.

Sono riuscito a compilare la cyanogenmod recovery. Ora si tratta solo di testarla. E come?

Mi ritrovo con questi file e directory (non incollo tutto il 'tree'):

Codice: Seleziona tutto

├── clean_steps.mk
├── external
├── kernel
├── obj
├── previous_build_config.mk
├── ramdisk-recovery.cpio
├── ramdisk-recovery.img
├── ramdisk.img
├── recovery
├── recovery.img
├── root
├── symbols
├── system
└── utilities
Vedo che c'è una recovery.img già pronta: che si fa, si "flasha" quella?

In 'utilities' ho questo:

Codice: Seleziona tutto

utilities/
├── recovery
├── unsigned.zip
└── update.zip
Quell'update.zip so cos'è: praticamente è la recovery "preparata" come aggiornamento firmware.

Ma non mi azzardo a muovere un dito.

Idee?

Ciao

ilmich
Master
Master
Messaggi: 1563
Iscritto il: lun 16 lug 2007, 17:39
Slackware: 14.2 64bit
Kernel: 4.19.46
Desktop: dwm
Località: Roma

Re: Sviluppo e hacking smartphone mediatek

Messaggio da ilmich »

rik70 ha scritto:Vedo che c'è una recovery.img già pronta: che si fa, si "flasha" quella?
si si devi flashare quella con spflashtool.. oppure usare lo zip se hai già una recovery che è in grado di fare l'update da zip...
Il resto sono i prodotti della compilazione (in particolare sotto recovery/ trovi il ramdisk esploso)

io pure sono andato un po' avanti, le mie prime build della cyanogenmod non partono, ma sono riuscito, grazie a questo link a costruirmi un cavo UART TTL usb per poter leggere i messaggi di boot tramite minicom e finalmente ho visto un po' di errori :)
comunque questi mediatek sono sicuramente ostici per via dello scarso supporto, ma per fare una cosa del genere sul mio telefono principale devo smontarlo e saldarci dei cavi :shock:
ho visto cose che voi astemi non potete immaginare
https://github.com/ilmich

rik70
Iper Master
Iper Master
Messaggi: 2207
Iscritto il: gio 10 mar 2011, 9:21
Slackware: 64-current
Kernel: 5.4.x
Desktop: Xfce 4.14
Distribuzione: Arch Linux

Re: Sviluppo e hacking smartphone mediatek

Messaggio da rik70 »

Ok, ho installato da SPFlash.

Risultato: impallato sul boot logo per un minuto circa e poi ha fatto l'avvio normale :D
Ma ce l'aspettavamo. Questo fine settimana ci torno su.

La faccenda comunque è tosta, anche se ho visto che ci sono build ufficiali dove non esiste una recovery CMR.
Ad esempio questa: https://wiki.cyanogenmod.org/w/Sprout_Info . Guarda caso parliamo di soc mediatek, il che in parte mi consola, visto che non sono riusciti nemmeno "loro".

Mi sa che me la tento con la TWRP. Dato che sei avanti anni luce, hai qualche dritta al volo da darmi? Che passaggi devo fare per tirare giù i sorgenti, sostituirli a quelli della recovery CMR e ricompilare?

Dénchiu.
miklos ha scritto:sono riuscito, grazie a questo link a costruirmi un cavo UART TTL usb per poter leggere i messaggi di boot tramite minicom e finalmente ho visto un po' di errori :)
:shock:

Non penso che sarei capace.

ilmich
Master
Master
Messaggi: 1563
Iscritto il: lun 16 lug 2007, 17:39
Slackware: 14.2 64bit
Kernel: 4.19.46
Desktop: dwm
Località: Roma

Re: Sviluppo e hacking smartphone mediatek

Messaggio da ilmich »

rik70 ha scritto:Risultato: impallato sul boot logo per un minuto circa e poi ha fatto l'avvio normale :D
Ma ce l'aspettavamo. Questo fine settimana ci torno su.
mi stai dicendo che non sei riuscito a farla andare?!? Io sono riuscito a farle andare entrambe (cm e twrp)
Verifica un attimo perchè la recovery è molto piu' semplice, magari è solo errato l'fstab, oppure l'hai compilata per un'architettura arm differente, o con un kernel non funzionante (sto enunciando le possibili cause)
rik70 ha scritto:Mi sa che me la tento con la TWRP. Dato che sei avanti anni luce, hai qualche dritta al volo da darmi? Che passaggi devo fare per tirare giù i sorgenti, sostituirli a quelli della recovery CMR e ricompilare?
scaricati lo zip dell'intero repository e sostituiscilo/rinomina il vecchio al posto di cio' che trovi dentro la directory {root_sorgente_cyanogenmod}/bootable/recovery/
Eppoi come di consueto compila con make -j3 recoveryimage, tieni conto pero' che se non funziona la cyanogen recovery è possibile che non funzioni nemmeno questa.
rik70 ha scritto:Non penso che sarei capace.
lo credevo anche io :)
ho visto cose che voi astemi non potete immaginare
https://github.com/ilmich

rik70
Iper Master
Iper Master
Messaggi: 2207
Iscritto il: gio 10 mar 2011, 9:21
Slackware: 64-current
Kernel: 5.4.x
Desktop: Xfce 4.14
Distribuzione: Arch Linux

Re: Sviluppo e hacking smartphone mediatek

Messaggio da rik70 »

miklos ha scritto:mi stai dicendo che non sei riuscito a farla andare?!? Io sono riuscito a farle andare entrambe (cm e twrp)
Verifica un attimo perchè la recovery è molto piu' semplice, magari è solo errato l'fstab, oppure l'hai compilata per un'architettura arm differente, o con un kernel non funzionante (sto enunciando le possibili cause)
Sì esatto, non riesco a farla andare. Ho tirato giù la tua cm, ed in effetti le cose sono un po diverse:

1 - la tua riesco a scompattarla con i MTK-Tools, la mia no: da un errore sull'archivio ramdisk, ma nessun problema invece con unpackbootimg e gunzip + cpio. Tu l'hai ricompattata con 'repack-MTK.pl' o è uscita fuori così?

2 - nella root della ramdisk ho un file 'fstab.goldfish' con questo contenuto
# Android fstab file.
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
/dev/block/mtdblock0 /system ext4 ro,barrier=1 wait
/dev/block/mtdblock1 /data ext4 noatime,nosuid,nodev,barrier=1,nomblk_io_submit wait,check
/dev/block/mtdblock2 /cache ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,check
/devices/platform/goldfish_mmc.0 auto vfat defaults voldmanaged=sdcard:auto
e non so cosa sia. in etc/ ho solo recovery.fstab che ricalca precisamente l'fstab della stock recovery e non l'ho toccato.
Nella tua cm invece vedo che ne hai 2, come mai? Che ci fa il twrp.fstab nella cm-recovery?
Questo è il mio tree:

Codice: Seleziona tutto

.
├── data
├── default.prop
├── dev
├── etc
├── file_contexts
├── fstab.goldfish
├── init
├── init.rc
├── proc
├── property_contexts
├── res
├── sbin
├── seapp_contexts
├── sepolicy
├── sys
├── system
├── tmp
├── ueventd.goldfish.rc
└── ueventd.rc
Quel goldfish leggo che ha che fare con Android Emulator.

Per la compilazione ho seguito questo:

Codice: Seleziona tutto

Use the following command to set up your build environment:
  lunch cm_a806-eng
And use the following command to build a recovery:
  . build/tools/device/makerecoveries.sh cm_a806-eng
Uhm... mi sa che mi sto incasinando e devo ripartire da capo.

Idee?

ilmich
Master
Master
Messaggi: 1563
Iscritto il: lun 16 lug 2007, 17:39
Slackware: 14.2 64bit
Kernel: 4.19.46
Desktop: dwm
Località: Roma

Re: Sviluppo e hacking smartphone mediatek

Messaggio da ilmich »

ahhhh ora è chiaro :) non è mediatek compliant la tua immagine. :)
la build della cyanogenmod compila le immagini nel formato standard, quello mediatek lo è un po' meno percio' o lo converti manualmente (unpack con i tool ufficiali e repack con quelli mediatek) oppure nel tuo device tree aggiungi questo file che io ho preso in giro da altri repository mediatek che prepara le immagini nel modo giusto.
nel tuo board config devi poi indicare che la tua build genera le immagini attraverso uno script custom

Codice: Seleziona tutto

#custom bootimg script
BOARD_CUSTOM_BOOTIMG_MK := device/cubot/x9/bootimg.mk
BOARD_MKBOOTIMG_ARGS := --board 1419997733
BOARD_CUSTOM_BOOTIMG := true
rik70 ha scritto: nella root della ramdisk ho un file 'fstab.goldfish' con questo contenuto
come hai scoperto in autonomia è l'fstab per l'emulatore. Sul mio non c'e' perchè ho raffinato la build in modo che le cose specifiche per l'emulatore non venissero considerate.
non mi ricordo bene come ho fatto, ma se non erro il file cm.mk include un make file

Codice: Seleziona tutto

$(call inherit-product, $(SRC_TARGET_DIR)/product/full.mk)
che sostanzialmente compila un bel po di roba.
Se ti fai un giro dentro quella directory troverai altri mk file che sono piu' specifici (ad esempio device senza telefonia etc etc etc) oppure puoi vedere cosa ho incluso io nel mio source tree ;)
rik70 ha scritto:Nella tua cm invece vedo che ne hai 2, come mai? Che ci fa il twrp.fstab nella cm-recovery?
per comodità, avendo un unico source tree mi è sufficiente cambiare il sorgente della recovery senza dover fare altro.
Tieni presente che tutte le recovery cercano il file /etc/recovery.fstab. La twrp ha la particolarità che se esiste anche il suo specifico (twrp.fstab) lo rinomina temporaneamente in recovery.fstab (facendo il backup dell'altro).

Il tuo processo di compilazione mi sembra corretto anche se io ottengo lo stesso risultato con

Codice: Seleziona tutto

source build/envsetup.sh
lunch cm_x9-userdebug
export USE_CCACHE=1 --> questo se vuoi velocizzare di motlo le compilazioni successive
make -j3 recoveryimage
ho visto cose che voi astemi non potete immaginare
https://github.com/ilmich

rik70
Iper Master
Iper Master
Messaggi: 2207
Iscritto il: gio 10 mar 2011, 9:21
Slackware: 64-current
Kernel: 5.4.x
Desktop: Xfce 4.14
Distribuzione: Arch Linux

Re: Sviluppo e hacking smartphone mediatek

Messaggio da rik70 »

Ok, grazie mille: i conti iniziano a tornare :)

Prenderò a prestito un po di roba da te, poi ci mettiamo d'accordo per le royalties 8)

Hai accennato alla faccenda della cpu sbagliata. Questo è l'output di 'lunch cm_a806-eng':

Codice: Seleziona tutto

[...]
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
TARGET_CPU_VARIANT=cortex-a7
[...]
È corretto secondo te?

Ho notato poi che hai fatto diverse modifiche ai file, tipo questo, dove tra l'altro hai inserito:

Codice: Seleziona tutto

TARGET_SCREEN_HEIGHT := 1280
TARGET_SCREEN_WIDTH := 720
Immagino sia importante. Una volta fatti questi cambiamenti cosa fai: ricompili direttamente o devi dare 'make clean' o cose simili?

ilmich
Master
Master
Messaggi: 1563
Iscritto il: lun 16 lug 2007, 17:39
Slackware: 14.2 64bit
Kernel: 4.19.46
Desktop: dwm
Località: Roma

Re: Sviluppo e hacking smartphone mediatek

Messaggio da ilmich »

rik70 ha scritto:È corretto secondo te?
.. dipende, mi sembra di ricordare che tu hai generato il tree con un comando presente nel sorgente cyanogemod. in quel caso i valori sono presi dal telefono e perciò sono corretti.
In ogni caso mi sa che non ti si avvia perchè è creata male l'immagine.
rik70 ha scritto:Ho notato poi che hai fatto diverse modifiche ai file, tipo questo, dove tra l'altro hai inserito:
si.. diciamo che partendo da zero ho piano piano cercato di far funzionare (senza successo per ora) una rom completa. Le righe che mi hai indicato servono, se compili la twrp, a selezionare il set di immagini ad-hoc per quella risoluzione. Se vuoi compilare la twrp devi aggiungere queste configurazioni (non so cosa succede diversamente perchè in questo ho seguito le informazioni di build ufficiali)
rik70 ha scritto: Una volta fatti questi cambiamenti cosa fai: ricompili direttamente o devi dare 'make clean' o cose simili?
io per sicurezza lo faccio, diciamo che se non lo fai va tutto a buon fine, ma rischi che il ramdisk contenga delle schifezze (magari hai spostato qualche file, rinominato). Insomma, dipende dal motivo della ricompilazione.
Tieni conto comunque che tutto il processo di build è fatto con tool standard (semplifico un po') perciò come quando compili un normale programma da sorgente con make la build compila eventualmente solo il delta o i file per i quali ad esempio hai cambiato/aggiunto qualche flag al compilatore.
ho visto cose che voi astemi non potete immaginare
https://github.com/ilmich

rik70
Iper Master
Iper Master
Messaggi: 2207
Iscritto il: gio 10 mar 2011, 9:21
Slackware: 64-current
Kernel: 5.4.x
Desktop: Xfce 4.14
Distribuzione: Arch Linux

Re: Sviluppo e hacking smartphone mediatek

Messaggio da rik70 »

Oh ca....volo ... è partita!

Come dicevi, andava ri-pacchettizzata coi MTK-Tools :thumbright:

Ci sono un po di cose che non vanno:

Codice: Seleziona tutto

can't open /dev/tty0: No such file or directory
I permessi:

Codice: Seleziona tutto

-rwxr-x---    1 root     root       1016280 Mar 24 16:39 /sbin/recovery
Questo l'avevo già visto nella ramdisk esplosa. Ho notato che nell'update.zip c'è uno script che "fissa" i permessi. Per esempio, quel /sbin/recovery dovrebbe essere '0755'. Anche la questione dei gruppi non torna: alcuni file e/o directory dovrebbero essere root:2000, giusto? Uhm.... eppure ho scompattato e ricompattato da root. Vabbè, vedremo di sistemare....

Poi ho questi errori relativi al dispositivo 'misc' che ho già incontrato in altre recovery custom:

Codice: Seleziona tutto

stat misc try 1: No such file or directory
stat misc try 2: No such file or directory
stat misc try 3: No such file or directory
stat misc try 4: No such file or directory
stat misc try 5: No such file or directory
stat misc try 6: No such file or directory
stat misc try 7: No such file or directory
stat misc try 8: No such file or directory
stat misc try 9: No such file or directory
stat misc try 10: No such file or directory
failed to stat misc
E:Can't open misc
(No such file or directory)
Ma non è il solo. Faccio prima a incollare il log della recovery: http://pastebin.com/y9T2m25Q

Poi è cambiato il vendor:

Codice: Seleziona tutto

Bus 005 Device 021: ID 18d1:d001 Google Inc.
:D, ma questo è facile da risolvere.

Comunque tutti i comandi adb funzionano, mentre i tasti non li ho provati.

ilmich
Master
Master
Messaggi: 1563
Iscritto il: lun 16 lug 2007, 17:39
Slackware: 14.2 64bit
Kernel: 4.19.46
Desktop: dwm
Località: Roma

Re: Sviluppo e hacking smartphone mediatek

Messaggio da ilmich »

rik70 ha scritto: Ho notato che nell'update.zip c'è uno script che "fissa" i permessi.
non ho mai flashato la recovery da zip, ma in tutti gli update lo fa perchè essendo appunto uno zip non vengono salvati gli attributi estesi (proprietario e permessi). di norma non serve e infatti flashando la recovery direttamente da file .img non hai nessuno problema. considera che nel caso specifico se fossero sbagliati non partirebbe niente, quello è il binario della recovery
rik70 ha scritto: Poi è cambiato il vendor:
io lo lascerei cosi'.. considera che spesso, soprattutto su windows ma anche su linux, ti dicono che bisogna installare i driver del telefono per usare l'adb, ma in realtà il driver è sempre quello cambia solo il fatto che il sistema da solo non conosce tutte le possibili accoppiate vendorid/deviceid (su linux ad esempio dovresti inserire una regola udev per poterlo usare con adb e mtp da utente regolare).
Se lo lasci cosi' invece viene riconosciuto come device google standard da tutti senza dover fare grandi pippe mentali. Almeno io sulla recovery l'ho lasciato cosi' (ancora una rom buona non ce l'ho )

Per quanto rigurarda il discorso /misc, sembra che non venga montata correttamente la partizione.. devo fare qualche test pero' per poterti provare ad aiutare meglio.
ho visto cose che voi astemi non potete immaginare
https://github.com/ilmich

rik70
Iper Master
Iper Master
Messaggi: 2207
Iscritto il: gio 10 mar 2011, 9:21
Slackware: 64-current
Kernel: 5.4.x
Desktop: Xfce 4.14
Distribuzione: Arch Linux

Re: Sviluppo e hacking smartphone mediatek

Messaggio da rik70 »

miklos ha scritto:Per quanto rigurarda il discorso /misc, sembra che non venga montata correttamente la partizione..
8)

Le tue preziose osservazioni e la scuola slackware aiutano. Buttando un occhio in /dev a telefono acceso ho scovato l'errore. E' bastato cambiare questo

Codice: Seleziona tutto

misc      				  /misc       emmc      defaults        defaults
in

Codice: Seleziona tutto

/dev/misc      				  /misc       emmc      defaults        defaults
nel recovery.fstab.

Ora la recovery fa il boot immediato e non va più in stallo per qualche secondo e non c'è nessun messaggio di errore a schermo.
Anche il log sembra più "pulito" - c'è solo qualche 'warning': http://pastebin.com/F4cwKTqn

Ora si tratta di verificare se i tasti vanno e provare le varie funzioni.

Edit:
I tasti funzionano - Volume +\- per navigare e tasto di accensione per selezionare gli elementi.

ilmich
Master
Master
Messaggi: 1563
Iscritto il: lun 16 lug 2007, 17:39
Slackware: 14.2 64bit
Kernel: 4.19.46
Desktop: dwm
Località: Roma

Re: Sviluppo e hacking smartphone mediatek

Messaggio da ilmich »

rik70 ha scritto:e la scuola slackware aiutano.
in quest'avventura in cui ci siamo infilati non puoi immaginare quanto mi sta aiutando :)

per quanto riguarda i warning

Codice: Seleziona tutto

__bionic_open_tzdata: couldn't find any tzdata when looking for localtime!
__bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
__bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!
questo lo danno tutti i binari linkati con le libc e dipende dal fatto che non trova il file /usr/share/tzdata (scusami, il percorso potrebbe non essere corretto perchè non ho a portata di mano l'attrezzo :) ) questo file in una compilazione full viene generato nella rom (non so se poi viene portato nella recovery), probabilmente quando si compila la sola recovery manca. In ogni caso' è fastidioso perchè in una shell adb appare persino con un semplice ls ma non mi è sembrato dare altri problemi e infatti io l'ho ignorato per il momento.

Codice: Seleziona tutto

W:Unable to get recovery.fstab info for /datadata during fstab generation!
W:Unable to get recovery.fstab info for /emmc during fstab generation!
W:Unable to get recovery.fstab info for /sd-ext during fstab generation!
W:Unable to get recovery.fstab info for /external_sd during fstab generation
questi secondo me li puoi ignorare, evidentemente la recovery prova a montare queste partizioni in ogni caso e non trovandole (puoi non avere una scheda sd esterna) lancia il warning.

per quanto riguarda i tasti, mi ricordavo che la recovery cyanogenmod fosse anche touch.

comunque sono contento che ora funzioni a dovere ;)
ho visto cose che voi astemi non potete immaginare
https://github.com/ilmich

rik70
Iper Master
Iper Master
Messaggi: 2207
Iscritto il: gio 10 mar 2011, 9:21
Slackware: 64-current
Kernel: 5.4.x
Desktop: Xfce 4.14
Distribuzione: Arch Linux

Re: Sviluppo e hacking smartphone mediatek

Messaggio da rik70 »

Vai che secondo me a piccoli passi ne usciamo 8)

Faccio un quadro della situazione.

Abbiamo una recovery custom funzionante, ma c'è un passaggio fondamentale da fare: editare lo fstab.

Attualmente infatti è in uso lo fstab della stock recovery - non l'ho toccato come dicevo prima, a parte la faccenda del /misc - ma a noi questo non ci serve, altrimenti rimanevamo con la stock e problema chiuso.

Il contenuto del recovery.fstab è questo:

Codice: Seleziona tutto

boot       				  /boot       emmc      defaults        defaults
/dev/block/mmcblk0p2      /cache      ext4      defaults        defaults
/dev/block/mmcblk0p3      /data       ext4      defaults        defaults
/dev/misc      				  /misc       emmc      defaults        defaults
recovery  				  /recovery   emmc      defaults        defaults
/dev/block/mmcblk0p4      /sdcard     vfat      defaults        defaults
/dev/block/mmcblk0p6      /system     ext4      defaults        defaults
Sotto invece metto il contenuto di dumchar_info che ci da l'esatta situazione di partizioni e dispositivi:

Codice: Seleziona tutto

Part_Name	Size	StartAddr	Type	MapTo	Region
preloader    0x0000000000040000   0x0000000000000000   2   /dev/misc-sd     BOOT_1
mbr          0x0000000000080000   0x0000000000000000   2   /dev/block/mmcblk0     USER
ebr1         0x0000000000080000   0x0000000000080000   2   /dev/block/mmcblk0p1   USER
pro_info     0x0000000000300000   0x0000000000100000   2   /dev/block/mmcblk0     USER
nvram        0x0000000000500000   0x0000000000400000   2   /dev/block/mmcblk0     USER
protect_f    0x0000000000a00000   0x0000000000900000   2   /dev/block/mmcblk0p2   USER
protect_s    0x0000000000a00000   0x0000000001300000   2   /dev/block/mmcblk0p3   USER
seccfg       0x0000000000040000   0x0000000001d00000   2   /dev/block/mmcblk0     USER
uboot        0x0000000000060000   0x0000000001d40000   2   /dev/block/mmcblk0     USER
bootimg      0x0000000000a00000   0x0000000001da0000   2   /dev/block/mmcblk0     USER
recovery     0x0000000000a00000   0x00000000027a0000   2   /dev/block/mmcblk0     USER
sec_ro       0x0000000000600000   0x00000000031a0000   2   /dev/block/mmcblk0p4   USER
misc         0x0000000000080000   0x00000000037a0000   2   /dev/block/mmcblk0     USER
logo         0x0000000000800000   0x0000000003820000   2   /dev/block/mmcblk0     USER
expdb        0x0000000000fe0000   0x0000000004020000   2   /dev/block/mmcblk0     USER
android      0x000000005e000000   0x0000000005000000   2   /dev/block/mmcblk0p5   USER
cache        0x0000000008000000   0x0000000063000000   2   /dev/block/mmcblk0p6   USER
usrdata      0x0000000337900000   0x000000006b000000   2   /dev/block/mmcblk0p7   USER
bmtpool      0x0000000001500000   0x00000000ffff00a8   2   /dev/block/mmcblk0     USER
Part_Name:Partition name you should open;
Size:size of partition
StartAddr:Start Address of partition;
Type:Type of partition(MTD=1,EMMC=2)
MapTo:actual device you operate
Da ciò si desume che attualmente la recovery sta "gestendo":

Codice: Seleziona tutto

protect_f    #  /dev/block/mmcblk0p2

protect_s   # /dev/block/mmcblk0p3 

sec_ro        # /dev/block/mmcblk0p4 

cache         # dev/block/mmcblk0p6 
Ma a noi 'sta roba non serve: piuttosto, cache a parte, abbiamo bisogno di gestire 'usrdata, android' e le sdcard - interna ed esterna.

Come fare?

Tu @miklos vedo che hai già risolto, creando un recovery.fstab personalizzato. Il problema è capire come muoversi.

Un aiuto forse ce lo può dare la recovery_cwm generata da MTK_Droid_Tools durante l'elaborazione del dump della stockrom. La recovery in questione ha questo fstab:

Codice: Seleziona tutto

# mount point	fstype	device	[device2]
/misc	emmc	/dev/misc
/data	ext4	/dev/block/mmcblk0p7
/system	ext4	/dev/block/mmcblk0p5
/cache	ext4	/dev/block/mmcblk0p6
/boot	emmc	/dev/bootimg
/recovery	emmc	/dev/recovery
/sdcard	vfat	/dev/block/mmcblk1p1	/dev/block/mmcblk1
/sd-ext	auto	/dev/block/mmcblk1p2
Mi sa che ci siamo quasi e la differenza credo si noti abbastanza bene.

La sintassi però è un po diversa. In particolare non capisco questo:

Codice: Seleziona tutto

/sdcard	vfat	/dev/block/mmcblk1p1	/dev/block/mmcblk1
Come mai usa 2 "device"? Sarà la faccenda della sdcard emulata?
La seconda notazione è che manca completamente la parte dei "flag" dei filesystem. Quindi mi pare che non si possa usare tale e quale, però può servire da riferimento.

Come procedere a questo punto?

@miklos mi sa che solo tu puoi fare luce.

Rispondi