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.
miklos
Master
Master
Messaggi: 1504
Iscritto il: lun lug 16, 2007 17:39
Slackware: 14.1 64bit
Kernel: 3.16.3
Desktop: openbox 3.5.2
Località: Roma

Re: Sviluppo e hacking smartphone mediatek

Messaggioda miklos » ven mar 25, 2016 13:50

rik70 ha scritto:Il contenuto del recovery.fstab è questo:
spero che tu non le abbia mai fatto fare qualcosa a sta recovery perchè guardando il tuo dumchar l'fstab che hai usato fino ad ora è totalmente errato :shock: come puoi notare anche dal fatto che quello generato dal tool è piu' coerente con le partizioni che hai postato
Ti commento per quello che so le partizioni a cosa corrispondono

Codice: Seleziona tutto

preloader    0x0000000000040000   0x0000000000000000   2   /dev/misc-sd     BOOT_1 --> questa è il software di avvio.. è l'unica partizione che se ti sbagli rende il telefono un fermalibro
mbr          0x0000000000080000   0x0000000000000000   2   /dev/block/mmcblk0     USER --> master boot record equivalente a quello di un hard disk comune
ebr1         0x0000000000080000   0x0000000000080000   2   /dev/block/mmcblk0p1   USER --> contiene anch'esso parte della tabella delle partizioni (ci sono degli hack che editando con un hex editor danno la possibilità di cambiare la dimensione delle partizioni.. qui' di solito ci sono tutte le partizioni montabili che riconosci da un device completo di numero e partizione ad esempio mmcblk0p3)
pro_info     0x0000000000300000   0x0000000000100000   2   /dev/block/mmcblk0     USER
nvram        0x0000000000500000   0x0000000000400000   2   /dev/block/mmcblk0     USER --> questa partizione contiene imei e configurazioni del modem e del touchscreen.. conviene farsi un backup perchè è l'unica cosa non reperibile in rete come immagine di salvataggio
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 --> il bootloader che si preoccupa di far partire il sistema, la recovery, l'animazione del caricamento a telefono spento.. insomma na specie di lilo
bootimg      0x0000000000a00000   0x0000000001da0000   2   /dev/block/mmcblk0     USER --> ramdisk di avvio del sistema
recovery     0x0000000000a00000   0x00000000027a0000   2   /dev/block/mmcblk0     USER --> recovery
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 --> contiene un ramdisk estraibile con i tool mediatek con tutte le immagini che appaiono all'accensione + le animazioni del caricamento a telefono spento
expdb        0x0000000000fe0000   0x0000000004020000   2   /dev/block/mmcblk0     USER
android      0x000000005e000000   0x0000000005000000   2   /dev/block/mmcblk0p5   USER --> sarebbe la partizione /system
cache        0x0000000008000000   0x0000000063000000   2   /dev/block/mmcblk0p6   USER --> sarebbe la partizione /cache
usrdata      0x0000000337900000   0x000000006b000000   2   /dev/block/mmcblk0p7   USER --> sarebbe la partizione /data
bmtpool      0x0000000001500000   0x00000000ffff00a8   2   /dev/block/mmcblk0     USER

detto questo io ti suggerisco di creare il tuo fstab di conseguenza tenendo presente che con una recovery le cose che devono essere montate sono ben poche. Dico questo perchè le operazioni (con la cyanogen recovery) sono installazione update e reset dati di fabbrica. Quindi le partizioni essenziali sono la /system, la /data, la /cache eppoi chiaramente eventuali supporti rimuovibili.

Per quanto riguarda il formato dell'fstab sono piu' ferrato con la twrp, ma di base il parsing su android è sui primi 3 campi ed eventualmente il 4to se ci sono opzioni particolari mentre il quinto che io sappia viene proprio ignorato (dalla recovery)
Detto questo fai un mapping tra il tuo dumchar e un fstab che ti consiglio di creare da zero e verifica che tutto funzioni correttamente.
ho visto cose che voi astemi non potete immaginare
https://github.com/ilmich

miklos
Master
Master
Messaggi: 1504
Iscritto il: lun lug 16, 2007 17:39
Slackware: 14.1 64bit
Kernel: 3.16.3
Desktop: openbox 3.5.2
Località: Roma

Re: Sviluppo e hacking smartphone mediatek

Messaggioda miklos » ven mar 25, 2016 13:53

chiaramente sta cosa che la vecchia recovery fosse buggata non mi stupisce. tieni presente che non so il tuo, ma il mio telefono essendo di importazione, è passato attraverso un processo di sblocco e occidentalizzazione. Anche nel mio caso era errato e infatti quando entravo in recovery il robottino di android era bello disteso :shock:
ho visto cose che voi astemi non potete immaginare
https://github.com/ilmich

rik70
Iper Master
Iper Master
Messaggi: 2092
Iscritto il: gio mar 10, 2011 9:21
Slackware: 14.2
Kernel: 5.0.21
Desktop: Xfce 4.14
Distribuzione: Arch Linux

Re: Sviluppo e hacking smartphone mediatek

Messaggioda rik70 » ven mar 25, 2016 14:41

miklos ha scritto:spero che tu non le abbia mai fatto fare qualcosa a sta recovery
Tranquillo non ho toccato nulla, a parte provare i comandi linux via adb shell e il reboot.

Mi sono accorto che qualcosa non andava grazie alle discussioni che abbiamo avuto sulla twrp e perché ho maneggiato molto con questa ultimamente.

Ad esempio, quando ho provato il reboot coi tasti è saltato fuori un messaggio che diceva se volevo rootare il dispositivo - lo è già - e allora ho capito che stava lavorando su partizioni che non c'entravano nulla.

Non ho chiaro però se la recovery stock è buggata oppure no. Non è che è il produttore che le congegna in quel modo proprio per non consentire la manipolazione del firmware? In effetti ad es. non è possibile fare nessun mount di /sytem.

Questo è il recovery.fstab di una rom ufficiale non moddata di un tablet che monta lo stesso soc nostro:

Codice: Seleziona tutto

boot                     /boot       emmc      defaults        defaults
/dev/block/mmcblk0p2      /cache      ext4      defaults        defaults
/dev/block/mmcblk0p3      /data       ext4      defaults        defaults
misc                    /misc       emmc      defaults        defaults
recovery                /recovery   emmc      defaults        defaults
/dev/block/mmcblk0p4      /sdcard     vfat      defaults        defaults
/dev/block/mmcblk0p6      /system     ext4      defaults        defaults

È identico al mio, o no? Io penso che sta cosa sia voluta.

Però queste recovery hanno anche un fstab - anzi più di uno: fstab, fstab.fat.nand, fstab.nand - nella root della ramdisk totalmente diverso. Esempio:

Codice: Seleziona tutto

# 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

/emmc@usrdata     /data               ext4      noatime,nosuid,nodev,noauto_da_alloc    wait,check,encryptable=footer
/emmc@protect_f   /protect_f          ext4      noatime,nosuid,nodev,noauto_da_alloc    wait,check
/emmc@protect_s   /protect_s          ext4      noatime,nosuid,nodev,noauto_da_alloc    wait,check
/devices/platform/mtk-msdc.0/mmc_host   auto      vfat      defaults        voldmanaged=sdcard0:emmc@fat,noemulatedsd
/devices/platform/mtk-msdc.1/mmc_host   auto      vfat      defaults        voldmanaged=sdcard1:auto
Sai di cosa si tratta? Sembra che abbia a che fare col check dei fylesystem. Vengono usati in recovery mode o ignorati? Uhm... troppe domande forse.

miklos ha scritto:il mio telefono essendo di importazione, è passato attraverso un processo di sblocco e occidentalizzazione.

Sì sì, torna il discorso anche se da me la recovery cosiddetta stock non dava problemi. Ma confesso che non c'ho fatto assolutamente nulla.

Ok, mi concentro sulla creazione di un fstab ad hoc.

miklos
Master
Master
Messaggi: 1504
Iscritto il: lun lug 16, 2007 17:39
Slackware: 14.1 64bit
Kernel: 3.16.3
Desktop: openbox 3.5.2
Località: Roma

Re: Sviluppo e hacking smartphone mediatek

Messaggioda miklos » ven mar 25, 2016 14:57

rik70 ha scritto:È identico al mio, o no? Io penso che sta cosa sia voluta.
in realtà non lo è.. è concezione errata che a parità di soc la tabella delle partizioni sia identica, ma non è sempre cosi'.. fa fede il file dumchar preso direttamente dal telefono.. questo file infatti viene generato a runtime dal kernel partendo anche dall'mbr ed ebr (non posso essere piu' preciso data l'impossibilità di spulciare un kernel per intero). in realtà credo che le recovery buggate derivino da questa errata assunzione.
per conferma tieni conto che pur avendo un mt6592 a me ad esempio la partizione/ system corrisponde /dev/block/mmcblk0p5 e non /dev/block/mmcblk0p6 (come del resto anche nel tuo caso stando almeno al dumchar che hai postato)
Infatti tu hai

Codice: Seleziona tutto

android      0x000000005e000000   0x0000000005000000   2   /dev/block/mmcblk0p5   USER --> sarebbe la partizione /system
cache        0x0000000008000000   0x0000000063000000   2   /dev/block/mmcblk0p6   USER --> sarebbe la partizione /cache
usrdata      0x0000000337900000   0x000000006b000000   2   /dev/block/mmcblk0p7   USER --> sarebbe la partizione /data
e il corrispettivo fstab dovrebbe essere

Codice: Seleziona tutto

/dev/block/mmcblk0p7   /data      ext4   
/dev/block/mmcblk0p5   /system      ext4   
/dev/block/mmcblk0p6   /cache      ext4
rik70 ha scritto:Però queste recovery hanno anche un fstab - anzi più di uno: fstab, fstab.fat.nand, fstab.nand - nella root della ramdisk totalmente diverso.
ignorale, a meno che negli script di init non decidi di usarli la recovery usa solo ed esclusivamente il file recovery.fstab. Sono sicuramente dei refusi nella recovery.. in altri contesti servono ma questo è n'altro discorso.. ma ai fini di compilare una recovery funzionante puoi anche non considerarli affatto.
ho visto cose che voi astemi non potete immaginare
https://github.com/ilmich

rik70
Iper Master
Iper Master
Messaggi: 2092
Iscritto il: gio mar 10, 2011 9:21
Slackware: 14.2
Kernel: 5.0.21
Desktop: Xfce 4.14
Distribuzione: Arch Linux

Re: Sviluppo e hacking smartphone mediatek

Messaggioda rik70 » ven mar 25, 2016 15:44

miklos ha scritto:in realtà non lo è.. è concezione errata che a parità di soc la tabella delle partizioni sia identica, ma non è sempre cosi'.. fa fede il file dumchar preso direttamente dal telefono..

Spetta, ma il dumchar coincide, guarda tu stesso:

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
ebr2         0x0000000000080000   0x0000000004020000   2   /dev/block/mmcblk0     USER
expdb        0x0000000000f60000   0x00000000040a0000   2   /dev/block/mmcblk0     USER
android      0x0000000080000000   0x0000000005000000   2   /dev/block/mmcblk0p5   USER
cache        0x0000000008000000   0x0000000085000000   2   /dev/block/mmcblk0p6   USER
usrdata      0x0000000080000000   0x000000008d000000   2   /dev/block/mmcblk0p7   USER
fat          0x000000028eb00000   0x000000010d000000   2   /dev/block/mmcblk0p8   USER
bmtpool      0x0000000001500000   0x00000000ffff00a8   2   /dev/block/mmcblk0     USER

Reincollo lo fstab per comodità di lettura:

Codice: Seleziona tutto

boot                     /boot       emmc      defaults        defaults
/dev/block/mmcblk0p2      /cache      ext4      defaults        defaults
/dev/block/mmcblk0p3      /data       ext4      defaults        defaults
misc                    /misc       emmc      defaults        defaults
recovery                /recovery   emmc      defaults        defaults
/dev/block/mmcblk0p4      /sdcard     vfat      defaults        defaults
/dev/block/mmcblk0p6      /system     ext4      defaults        defaults


Vedi dunque che anche in questo caso la stock recovery si comporta in modo analogo:

- come cache e data utilizza protect_f e protect_s;
- come system monta - ma guarda che storia - la cache (/dev/block/mmcblk0p6);
- infine sdcard è /dev/block/mmcblk0p4 che altro non è che 'sec_ro'

E questa invece l'ho testata eccome, con 3 aggiornamenti fota, wipe+reset di fabbrica.

Secondo me sono congegnate così apposta.
Della serie: anche se riesci a guadagnare un accesso alla shell via adb, se gli dai un 'mount /system' ti tira su il dito medio e monta la 'cache' :lol:

miklos ha scritto:ignorale, a meno che negli script di init non decidi di usarli la recovery usa solo ed esclusivamente il file recovery.fstab.
Ok.
miklos ha scritto:fstab dovrebbe essere

Codice: Seleziona tutto
/dev/block/mmcblk0p7 /data ext4
/dev/block/mmcblk0p5 /system ext4
/dev/block/mmcblk0p6 /cache ext4
Bene, grazie mille. Ora mi resta da capire come gestire il mount, cioè cosa far montare in automatico all'avvio della recovery, se in sola lettura, etc.... mi serve qualche esempio da cui copiare.

Poi passo alla TWRP.

rik70
Iper Master
Iper Master
Messaggi: 2092
Iscritto il: gio mar 10, 2011 9:21
Slackware: 14.2
Kernel: 5.0.21
Desktop: Xfce 4.14
Distribuzione: Arch Linux

Re: Sviluppo e hacking smartphone mediatek

Messaggioda rik70 » mer mar 30, 2016 9:55

Lasciando perdere le mie ultime congetture, sono finalmente su con la recovery TWRP 3.x.x installata e funzionante.

Il touchpad è perfetto al primo colpo, il mount pure - riconosce la sd emulata e crea in automatico il punto di montaggio - ma anche io sono incappato nel problema del reboot/poweroff: non va e il citofon si pianta di brutto.

@miklos: per il momento ho brutalmente copiato i tuoi script e funzionano, ma sarei curioso di sapere dove sta l'inghippo. Ho infatti compilato anche la TWRP 2.8.5.0 e questa non è affetta dal problema.

Ora devo capire dove sta il sensore di temperatura della CPU.

Comunque sono molto indietro col "comprendonio". Ad esempio non mi è ancora chiaro come usare correttamente la variabile 'PRODUCT_COPY_FILES'. In pratica non riesco a copiare twrp.fstab nella etc della root della ramdisk al termine della compilazione. Per adesso faccio tutto a "manina". Idee?

P.s.
ho notato che in 'bootable/' ci sono 2 directory: recovery e recovery-cm. La seconda sembra contenere la "vera" recovery cyanogen.

miklos
Master
Master
Messaggi: 1504
Iscritto il: lun lug 16, 2007 17:39
Slackware: 14.1 64bit
Kernel: 3.16.3
Desktop: openbox 3.5.2
Località: Roma

Re: Sviluppo e hacking smartphone mediatek

Messaggioda miklos » mer mar 30, 2016 12:14

[/quote]
rik70 ha scritto:Lasciando perdere le mie ultime congetture, sono finalmente su con la recovery TWRP 3.x.x installata e funzionante.
ottimo
rik70 ha scritto:ma anche io sono incappato nel problema del reboot/poweroff: non va e il citofon si pianta di brutto.
non l'ho capito bene nemmeno io, inizialmente pensavo fosse un problema di binari che non trovava (e non sono sicurissimo non sia questo il problema) ma ho pure il sospetto che questa twrp faccia una chiamata al kernel e per qualche motivo quello precompilato mediatek non funzioni a dovere.
rik70 ha scritto:Ora devo capire dove sta il sensore di temperatura della CPU.
gira intorno al seguente percorso

Codice: Seleziona tutto

TW_CUSTOM_CPU_TEMP_PATH := /sys/class/thermal/thermal_zone1/temp

rik70 ha scritto:Ad esempio non mi è ancora chiaro come usare correttamente la variabile 'PRODUCT_COPY_FILES'. In pratica non riesco a copiare twrp.fstab nella etc della root della ramdisk al termine della compilazione. Per adesso faccio tutto a "manina". Idee?
è nel formato

Codice: Seleziona tutto

$(LOCAL_PATH)(percorso relativo al tuo device tree):(percorso relativo di destinazione)
se ad esempio vuoi copiare della roba nella recovery

Codice: Seleziona tutto

$(LOCAL_PATH)/rootdir/etc/firmware/gt9xx_config.bin:recovery/root/etc/firmware/gt9xx_config.bin \
mentre se vuoi farlo nel ramdisk

Codice: Seleziona tutto

$(LOCAL_PATH)/rootdir/etc/firmware/gt9xx_config.bin:root/etc/firmware/gt9xx_config.bin
ho visto cose che voi astemi non potete immaginare
https://github.com/ilmich

rik70
Iper Master
Iper Master
Messaggi: 2092
Iscritto il: gio mar 10, 2011 9:21
Slackware: 14.2
Kernel: 5.0.21
Desktop: Xfce 4.14
Distribuzione: Arch Linux

Re: Sviluppo e hacking smartphone mediatek

Messaggioda rik70 » mer mar 30, 2016 13:46

miklos ha scritto:ma ho pure il sospetto che questa twrp faccia una chiamata al kernel e per qualche motivo quello precompilato mediatek non funzioni a dovere.

Il problema parte dal branch android-5.1 - quindi dalla twrp 2.8.6.x o qualcosa del genere. Guarda qui, a un certo punto c'è un commit del 25 Marzo 2015 "intitolato": Fix reboot for some devices Ma vai a mettere mano al codice... ma forse con un revert di questo... se provo ti faccio sapere.

miklos ha scritto:è nel formato

Codice: Seleziona tutto
$(LOCAL_PATH)(percorso relativo al tuo device tree):(percorso relativo di destinazione)
Ok. Ma va messo in BoardConfig.mk o... ?
Ultima modifica di rik70 il mer mar 30, 2016 22:09, modificato 1 volta in totale.

miklos
Master
Master
Messaggi: 1504
Iscritto il: lun lug 16, 2007 17:39
Slackware: 14.1 64bit
Kernel: 3.16.3
Desktop: openbox 3.5.2
Località: Roma

Re: Sviluppo e hacking smartphone mediatek

Messaggioda miklos » mer mar 30, 2016 13:59

rik70 ha scritto:Il problema parte dal branch android-5.1 - quindi dalla twrp 2.8.6.x o qualcosa del genere. Guarda qui, a un certo punto c'è un commit del 25 Marzo 2015 "intitolato": Fix reboot for some devices Ma vai a mettere mano al codice... ma forse con un reverse di questo... se provo ti faccio sapere.
io una piccola fix sulla twrp l'ho fatta(altro piccolo bug).. pero' il giro per farla entrare è allucinante.. magari ci do' un'occhiata.. questo effettivamente sarebbe da correggere
rik70 ha scritto:Ok. Ma va messo in BoardConfig.mk o... ?
tecnicamente non c'e' un vincolo, nel senso che puoi metterlo in un qualsiasi file .mk. Io mi sono dato la regola di cercare di mettere nel BoardConfig le cose 'comuni' al chipset e quanto piu' indipendenti dall'android che si sta 'compilando' mentre nel file device_x9.mk le cose specifiche del telefono e della rom (applicazioni, file di ramdisk e via dicendo)
ho visto cose che voi astemi non potete immaginare
https://github.com/ilmich

miklos
Master
Master
Messaggi: 1504
Iscritto il: lun lug 16, 2007 17:39
Slackware: 14.1 64bit
Kernel: 3.16.3
Desktop: openbox 3.5.2
Località: Roma

Re: Sviluppo e hacking smartphone mediatek

Messaggioda miklos » mer mar 30, 2016 14:04

miklos ha scritto:pero' il giro per farla entrare è allucinante
intendo dire che contribuire al progetto è un po' tortuoso per uno che ha già non pochi account in giro per la rete e da github i commit non li accettano :)
ho visto cose che voi astemi non potete immaginare
https://github.com/ilmich

miklos
Master
Master
Messaggi: 1504
Iscritto il: lun lug 16, 2007 17:39
Slackware: 14.1 64bit
Kernel: 3.16.3
Desktop: openbox 3.5.2
Località: Roma

Re: Sviluppo e hacking smartphone mediatek

Messaggioda miklos » mer mar 30, 2016 14:51

forse ho capito perchè non va il reboot in recovery. guardando il codice che mi hai postato ho scoperto che da android kitkat il processo di reboot è effettuato scrivendo nella proprieta di sistema

Codice: Seleziona tutto

sys.powerctl=valore
Ho notato che nei miei script di init della recovery non c'e' questo pezzo

Codice: Seleziona tutto

on property:sys.powerctl=*
   powerctl ${sys.powerctl}
Appena possibile provo e ti faccio sapere :)
ho visto cose che voi astemi non potete immaginare
https://github.com/ilmich

rik70
Iper Master
Iper Master
Messaggi: 2092
Iscritto il: gio mar 10, 2011 9:21
Slackware: 14.2
Kernel: 5.0.21
Desktop: Xfce 4.14
Distribuzione: Arch Linux

Re: Sviluppo e hacking smartphone mediatek

Messaggioda rik70 » mer mar 30, 2016 16:23

miklos ha scritto:forse ho capito perchè non va il reboot in recovery. guardando il codice che mi hai postato ho scoperto che da android kitkat il processo di reboot è effettuato scrivendo nella proprieta di sistema

Codice: Seleziona tutto

sys.powerctl=valore
Ho notato che nei miei script di init della recovery non c'e' questo pezzo

Codice: Seleziona tutto

on property:sys.powerctl=*
   powerctl ${sys.powerctl}
Appena possibile provo e ti faccio sapere :)
Ok, faccio andare te per primo allora :thumbright:

Anche perché io di script init non ne ho toccato, viaggio solo con quello che ha generato la compilazione - e qui mi sa che nel caso mi dovrai aiutare ancora.

Nel frattempo ho sistemato la faccenda della temperatura della cpu - il percorso era questo:

Codice: Seleziona tutto

/sys/devices/virtual/thermal/thermal_zone1/temp

- e del twr.fstab.

Per l'ultimo punto, ho dovuto creare il percorso relativo nel device tree, altrimenti non lo copiava:

Codice: Seleziona tutto

├── AndroidBoard.mk
├── AndroidProducts.mk
├── BoardConfig.mk
├── bootimg.mk
├── cm.mk
├── device_a806.mk
├── kernel
├── recovery
│   └── root
│       └── etc
│           └── twrp.fstab
├── recovery.fstab
└── system.prop

Ti risulta? Poi ho messo questo in device_a806.mk:

Codice: Seleziona tutto

PRODUCT_COPY_FILES += \
        $(LOCAL_PATH)/recovery/root/etc/twrp.fstab:recovery/root/etc/twrp.fstab

rik70
Iper Master
Iper Master
Messaggi: 2092
Iscritto il: gio mar 10, 2011 9:21
Slackware: 14.2
Kernel: 5.0.21
Desktop: Xfce 4.14
Distribuzione: Arch Linux

Re: Sviluppo e hacking smartphone mediatek

Messaggioda rik70 » mer mar 30, 2016 22:24

Dato che

Codice: Seleziona tutto

grep powerc twrp-3/target/product/a806/recovery/root/init.rc
on property:sys.powerctl=*
   powerctl ${sys.powerctl}
alla fine mi son portato avanti col lavoro.

Basandomi sul commit di cui dicevamo sopra, ho approntato 2 patch che allego:

- una è per la twrp 2.8.6;

- l'altra è per la 3.0.0.

La patch per la twrp 3 restituisce un fuzzy - si dice così? - in quanto è derivata dalla prima (c'era una stringa in più nel sorgente) ma non da errori.

Incredibile ma vero, ora entrambe le recovery sembrano funzionare bene.

Edit:
oops... no, la twrp 3.0 non funziona come dovrebbe: piantare non si pianta, ma fa solo il reboot del sistema anche scegliendo le altre opzioni.
Allegati
twrp-3.0-mediatek-6592.patch
(2.99 KiB) Scaricato 54 volte
twrp-2.8.6-mediatek-6592.patch
(2.97 KiB) Scaricato 45 volte

miklos
Master
Master
Messaggi: 1504
Iscritto il: lun lug 16, 2007 17:39
Slackware: 14.1 64bit
Kernel: 3.16.3
Desktop: openbox 3.5.2
Località: Roma

Re: Sviluppo e hacking smartphone mediatek

Messaggioda miklos » gio mar 31, 2016 12:19

rik70 ha scritto:alla fine mi son portato avanti col lavoro.
anche io, e ho scoperto che funziona tutto tranne che il reboot da recovery (cosa piuttosto inutile se ci pensi)
Il problema è che se da shell adb provo

Codice: Seleziona tutto

setprop sys.powerctl=reboot,  # reboot di sistema
setprop sys.powerctl=reboot,recovery  # reboot in recovery
setprop sys.powerctl=shutdown,  # spegnimento
funziona tutto alla perfezione (che poi guardando il codice del comando reboot è quello che fa)
Mi sa che bisogna mettere mano alla recovery :) Pero' se riusciamo a risolverla mi sa che poi ci tocca condividere :badgrin:
ho visto cose che voi astemi non potete immaginare
https://github.com/ilmich

rik70
Iper Master
Iper Master
Messaggi: 2092
Iscritto il: gio mar 10, 2011 9:21
Slackware: 14.2
Kernel: 5.0.21
Desktop: Xfce 4.14
Distribuzione: Arch Linux

Re: Sviluppo e hacking smartphone mediatek

Messaggioda rik70 » gio mar 31, 2016 13:19

Bho, alla fine della fiera i tuoi script sembrano una soluzione accettabile, visto che trovano puntuale riscontro nel codice del reboot.

Comunque una cosa possiamo darla per certa: il problema inizia con quel commit sul branch android-5.1.

Non so se hai provato a compilare la 2.8.6.0, ma da lo stesso identico problema della 3 - il mio telefono va letteralmente in crash e devo staccare la batteria per resuscitarlo. Con la patch che ho allegato sopra invece va liscio come l'olio.

miklos ha scritto:Il problema è che se da shell adb provo

Codice: Seleziona tutto
setprop sys.powerctl=reboot, # reboot di sistema
setprop sys.powerctl=reboot,recovery # reboot in recovery
setprop sys.powerctl=shutdown, # spegnimento

funziona tutto alla perfezione (che poi guardando il codice del comando reboot è quello che fa)


Esatto. Anche se non ne capisco molto, secondo me il problema sta in questi cambiamenti:

Codice: Seleziona tutto

return property_set(ANDROID_RB_PROPERTY, "reboot,recovery");
anziché

Codice: Seleziona tutto

property_set(ANDROID_RB_PROPERTY, "reboot,recovery");

Ma confesso che è troppo per me.

Il problema ora è: chi ci parla con "questi"?
In pratica per risolvere problemi di "altri" ci hanno tagliato completamente fuori :D