Il y a des projets qu’on repousse.
Et il y a des tablettes qui traînent dans un tiroir depuis huit mois, transformées en presse-papier après une tentative de ROM Treble qui a mal tourné.
La mienne, une Lenovo Tab P11 Pro (TB-J706F, alias Xiaoxin Pad Pro 2021 côté chinois), faisait clairement partie de la seconde catégorie.
Spoiler : elle est vivante, elle tourne sous Android 16, et j’ai appris beaucoup trop de choses sur les bootloaders Qualcomm au passage.
Cet article est à la fois un récit, avec les impasses parce que c’est ça qui est drôle, et un tuto réutilisable si vous galérez avec le même modèle.
Tout s’est fait sous Linux, depuis mon serveur headless (celui qui héberge mes services self-hosted).
Accrochez-vous, c’est long.
Comme la vraie session.
Le patient
Pour situer : la P11 Pro / Xiaoxin repose sur un Snapdragon 730G (SM6150), avec stockage UFS, partitions dynamiques via le fameux super, et architecture A/B.
Bref, une tablette Qualcomm assez moderne, avec tout ce que ça implique de joyeusetés côté bootloader.
Le crime originel : j’avais voulu lui coller une GSI Treble.
Ça avait planté.
Depuis, écran noir, plus rien.
J’avais même acheté un « câble EDL », en gros un câble avec certaines broches court-circuitées pour essayer de forcer le mode usine.
Il n’avait jamais rien donné.
J’ai donc appliqué une technique de dépannage éprouvée : mettre la tablette dans un tiroir et ne plus y penser pendant huit mois.
Puis un jour je me suis dit qu’il fallait quand même régler ça.
Étape 0 : la batterie, cette ennemie jurée
Premier obstacle, et elle va revenir plusieurs fois dans l’histoire : la batterie.
Huit mois débranchée après un brick, elle était en décharge profonde.
Tellement basse que le SoC ne répondait même plus en USB :
lsusbRien.
Pas de périphérique inconnu, pas de Qualcomm, que dalle.
La solution était finalement très compliquée : la brancher sur un chargeur mural et attendre.
Pas sur un port USB de PC. Sur un vrai chargeur.
Au bout d’un moment, elle s’est réveillée toute seule sur un écran de logs du PBL, le Primary Boot Loader, le premier étage de boot gravé directement dans le SoC :
S - QC_IMAGE VERSION STRING-BOOT.XF.3.1-00589-SM6150L2B-2
S - Boot Interface: UFS
S - Secure Boot: OnBonne nouvelle : le SoC est vivant.
Moins bonne nouvelle : il ne trouve manifestement rien de valide à charger ensuite.
Merci la GSI.
Et surtout :
Secure Boot: OnÀ retenir pour la suite. Ça veut dire qu’on ne pourra pas juste balancer n’importe quel loader trouvé au fond d’un forum XDA et espérer que Qualcomm soit d’accord.
Le mode EDL, enfin
Petit rappel pour ceux qui n’ont jamais eu la joie de bricker un appareil Qualcomm : le mode EDL (Emergency Download) est un mode de secours qui permet de reflasher un appareil même quand presque tout le reste est mort.
Sur certains anciens appareils, un câble EDL suffit.
Sur celui-là, visiblement non.
Il faut soit un point de test sur la carte mère, soit réussir à tomber dessus autrement.
Après quelques manips, la tablette a fini par s’y retrouver toute seule.
Et là :
$ lsusb | grep 05c6
Bus 001 Device 004: ID 05c6:900e Qualcomm, Inc. QUSB_BULKEnfin un signe de vie.
Le SoC répond, on peut lui parler.
Reste juste à trouver le bon firmware, le bon loader et le bon outil.
Trois détails.
Le firmware : SVC vs USR, premier piège
Lenovo distribue plusieurs types de firmwares pour cette tablette.
J’ai commencé par prendre un package SVC (Service), donc en gros le firmware utilisé pour les opérations de réparation / SAV.
Il contenait tout ce qu’il fallait :
prog_firehose_ddr.elf- les
rawprogram*.xml - les images des partitions
- enfin presque tout
Gardez bien le « presque ».
Il va revenir plus tard.
Premier plantage : edl et son handshake capricieux
Sous Linux, l’outil de référence pour communiquer en EDL est edl de bkerler.
Je lance le flash.
Le mode Sahara est bien détecté.
Sahara, c’est le protocole Qualcomm utilisé notamment pour envoyer le loader Firehose au SoC.
Sauf que chez moi, l’outil part ensuite bizarrement sur du streaming, un vieux protocole HDLC, au lieu de continuer avec Firehose.
Résultat : timeout, timeout et encore timeout…
Et forcément, à ce moment-là, j’ai fait ce que fait n’importe quel développeur quand une librairie mature ne fonctionne pas comme prévu : j’ai commencé à supposer que le problème venait de la librairie.
J’ai donc passé beaucoup trop de temps à décortiquer des trames Sahara à la main :
04 00 00 00 10 00 00 00 …Puis à lire sahara.py.
Je l’ai patché.
Ensuite, je commence à me rendre compte que mon diagnostic était probablement mauvais.
J’annule mon patch.
Bref, un rabbit hole assez classique.
À la fin, j’en savais plus sur Sahara qu’au début, ce qui était techniquement un progrès, même si la tablette était toujours morte.
Le twist : fastboot était là depuis le début
En jouant avec les combos Power / Volume, l’écran finit soudainement par afficher :
The bootloader is unlocked and software integrity cannot be guaranteed
Attendez.
Unlocked ?
Quelques essais plus tard, avec le bon combo et surtout le bon timing, j’arrive en fastboot.
$ fastboot devices
HA1B4YB2 fastbootPuis :
$ fastboot getvar all | grep -iE "unlocked|current-slot|product"
(bootloader) unlocked:yes
(bootloader) current-slot:a
(bootloader) product:sm6150Bootloader déverrouillé.
Slot A actif.
Fastboot fonctionnel.
Donc, en résumé, toute la galère avec EDL, Sahara, Firehose et mes magnifiques patches Python aurait potentiellement pu être évitée.
Bon.
Au moins j’ai appris des trucs.
La batterie, encore elle
Je commence à flasher.
Et immédiatement :
Writing 'vbmeta_system_a' FAILED (remote: 'Warning: battery's capacity is very low')Ah.
La batterie.
Le bootloader refuse d’écrire sous un certain seuil, ce qui est plutôt logique. Perdre l’alimentation en plein flash d’une partition critique, ça manque légèrement d’élégance.
Le problème, c’est qu’en fastboot la tablette ne charge quasiment pas.
Je l’ai laissée branchée toute une nuit sur l’USB du serveur.
Résultat :
3566 mV -> 3710 mVAutant dire qu’on n’était pas pressés.
Et j’ai découvert au passage un autre coupable : le câble.
J’utilisais celui d’un casque SteelSeries Arctis, un câble « charge only » assez fin.
Je l’ai remplacé par mon vieux câble OnePlus rouge, prévu pour encaisser du 6A.
La différence était nette.
Moralité : avant d’accuser Qualcomm, le bootloader, la batterie ou la pleine lune, testez quand même un autre câble.
Le flash fastboot : vbmeta, boot et le monstre super
Une fois assez de batterie pour que le bootloader arrête de râler, j’ai pu commencer sérieusement.
D’abord AVB :
fastboot --disable-verity --disable-verification flash vbmeta_a vbmeta.img
fastboot --disable-verity --disable-verification flash vbmeta_system_a vbmeta_system.imgPuis les partitions de boot :
fastboot flash boot_a boot.img
fastboot flash dtbo_a dtbo.img
fastboot flash recovery_a recovery.imgJusque-là, ça va.
Puis arrive super.
Le package SVC contient plusieurs fichiers :
super_1.img
super_2.img
super_3.img
super_4.imgMon premier réflexe a été de supposer que c’étaient des chunks sparse d’une même image super.
Donc je les ai traités comme tels.
Erreur.
Un petit :
file super_2.img super_3.img super_4.imgdonne :
super_2.img: ext2 filesystem data
super_3.img: ext2 filesystem data, volume name "system_ext"
super_4.img: ext2 filesystem data, volume name "product"Ah.
Ce ne sont pas des morceaux.
Ce sont carrément les images des partitions logiques.
En gros :
systemsystem_extproduct- etc.
Ces partitions vivent dans super, mais elles se flashent individuellement depuis fastbootd, le fastboot userspace.
Oui, il y a fastboot et fastbootd.
Parce que sinon ce serait trop simple.
On passe donc en fastbootd :
fastboot reboot fastbootPuis :
fastboot getvar is-userspacequi doit répondre :
yesEt là :
fastboot flash system_a super_2.img
fastboot flash system_ext_a super_3.img
fastboot flash product_a super_4.imgTout est flashé.
Reboot.
Logo Lenovo.
Écran bootloader unlocked.
Logo Lenovo.
Écran bootloader unlocked.
Logo Lenovo.
Bref.
Bootloop.
Le vendor fantôme
Je vérifie tout.
AVB désactivé ? Oui.
Slot correct ? Oui.
Boot ? Oui.
System ? Oui.
Product ? Oui.
System_ext ? Oui.
Et là je remarque un détail légèrement important.
Le package SVC ne contient pas de vendor.
Voilà le fameux « presque ».
Le SVC étant un firmware de service, il part du principe que certaines partitions déjà présentes sur l’appareil sont encore utilisables.
Notamment vendor.
Sauf que ma GSI Treble précédente avait justement laissé la tablette dans un état assez douteux.
J’avais donc mis un system tout neuf par-dessus un vendor potentiellement incohérent.
Étonnamment, ça bootait mal.
Je télécharge donc cette fois un package USR / qpst complet.
Et là :
$ file super_5.img
super_5.img: ext2 filesystem data, volume name "vendor"Bingo.
Le vendor manquant.
Leçon n°1 : le firmware SVC n’est pas forcément suffisant pour une restauration complète.
Dans mon cas, après un bricolage Treble, il fallait clairement le package USR/qpst pour récupérer un vendor propre.
Reconstruire le super avec lpmake
Évidemment, à ce stade, fastbootd décide lui aussi de ne plus démarrer correctement.
Sinon ce ne serait pas drôle.
Impossible donc de reflasher les partitions logiques individuellement.
La solution : reconstruire une image super complète avec lpmake, puis la flasher directement sur la partition physique depuis fastboot classique.
lpmake \
--metadata-size 65536 --metadata-slots 2 \
--device super:12884901888 \
--group main_a:5400000000 \
--partition system_a:readonly:1808916480:main_a --image system_a=super_2.img \
--partition system_ext_a:readonly:391045120:main_a --image system_ext_a=super_3.img \
--partition product_a:readonly:2347741184:main_a --image product_a=super_4.img \
--partition vendor_a:readonly:691806208:main_a --image vendor_a=super_5.img \
--sparse --output super_new.imgPuis :
fastboot flash super super_new.imgCette fois, fastbootd redémarre.
Les partitions logiques sont bien là.
vendor compris.
Et surtout, Android va beaucoup plus loin au boot.
Enfin.
Le boss final : « not compatible with the hardware »
La tablette arrive jusqu’à l’écran de configuration Android.
Je commence presque à croire que c’est gagné.
Et là :
The current system is not compatible with the hardware. The device will power off automatically.
Puis elle s’éteint.
Très bien.
Cette fois, le problème vient du fait que ma tablette est en réalité un hardware Xiaoxin chinois livré par banggood sous firmware global. J’avais, à l’époque, modifié son flag région pour passer sur ZUI qui supportait Android 13 (la version global s’arrêtant à Android 12).
Ce flag est stocké dans la configuration Qualcomm / QCN.
Dans mon cas :
01 = China
02 = Global / ROWJ’avais donc un appareil configuré China, avec un firmware ROW.
Lenovo détecte le mismatch et refuse de démarrer.
C’est un garde-fou anti-conversion.
Et il marche très bien, je confirme.
La solution propre
La vraie solution est bien documentée par la commu Lenovo et consiste à remettre le bon flag région :
- backup de la QCN
- édition hexa du flag
01vers02 - restauration de la QCN via QFIL
Sauf que :
- je suis sous Linux
- QFIL est un outil Windows
- le port diag de la tablette ne parlait pas un QCDM standard facilement exploitable
- je n’avais pas de Windows sous la main
Donc, impasse.
Et là j’ai réalisé un truc.
Le plan B qui devient le plan A : une GSI
Le check région est fait par qui ?
Le système Lenovo.
Une GSI, par définition, est un système générique qui vient tourner au-dessus du vendor du constructeur grâce à Project Treble.
Donc elle ne contient pas le code Lenovo qui fait le check de région.
Et là, l’ironie était quand même assez belle.
C’est une GSI qui avait brické la tablette.
C’est une GSI qui allait la sauver.
Le vendor S630572 que je venais de reflasher était basé sur Android 13.
Je pouvais donc le garder et remplacer uniquement system.
Petit problème : la partition system était trop petite pour ma GSI.
Mais product n’est pas vraiment utile dans cette configuration.
Donc on va tout casser (oui, encore) :
fastboot reboot fastboot
fastboot delete-logical-partition product_aÇa libère de la place.
Puis :
fastboot flash system lineage-21.0-...-arm64_bgN-signed.imgRetour en bootloader :
fastboot reboot bootloaderOn désactive à nouveau AVB :
fastboot --disable-verity --disable-verification flash vbmeta_a vbmeta.imgPuis nettoyage :
fastboot erase userdata
fastboot erase metadata
fastboot rebootÀ noter : les variantes bgN de certaines GSI, notamment chez AndyYan / Doze-off, embarquent déjà les Google Apps.
Ça évite d’avoir à flasher des GApps via recovery.
Et quand on n’a que le recovery stock, c’est clairement pas plus mal.
Résurrection
Reboot.
Logo Lenovo. (Stress)
Puis animation LineageOS.
Puis :
Hi there
Android.
0 check région, 0 bootloop, 0 extinction automatique.
La tablette est ressuscitée.
En plus de ça, maintenant qu’Android tourne vraiment, la charge normale s’active enfin.
Fin du feuilleton batterie.
Leçon n°2 : un check de compatibilité région spécifique à Lenovo n’existe pas dans une GSI.
Donc en gardant le bon vendor et en remplaçant uniquement system, on contourne complètement le problème.
Épilogue : Android 16, parce qu’on peut
Une fois LineageOS 21 avec Android 14 stable et la batterie rechargée, j’aurais pu m’arrêter là.
La tablette fonctionnait, tout allait bien.
Mais évidemment, en tant que geek qui se respecte, j’ai voulu tester la dernière version d’android…
Cette fois une GSI crDroid Android 16, variante GAPPS.
Même procédure : vendor Android 13, system Android 16.
Trois générations d’écart.
Sur une tablette de 2021 qui était encore un presse-papier quelques heures plus tôt.
Et ça boote, le « Hi there » est revenu.
En 2026.
Sur cette tablette.
TL;DR : les trucs à retenir
- La batterie d’abord : en décharge profonde, l’appareil peut ne même plus apparaître en USB. Chargeur mural, bon câble, patience.
- Fastboot charge très mal sur cette tablette : ne comptez pas dessus pour récupérer rapidement une batterie vide.
- Testez fastboot avant l’EDL : Si le bootloader est déverrouillé, c’est beaucoup plus simple.
- SVC != USR. Dans mon cas, le firmware SVC n’avait pas de
vendor. Le package USR/qpst, oui. - Les
super_N.imgn’étaient pas des chunks. C’étaient des partitions logiques séparées. - Fastbootd sert à manipuler les partitions dynamiques. Si fastbootd est cassé,
lpmakepermet de reconstruire unsuper. - Le firmware Lenovo ROW vérifie la région du hardware.
- Une GSI n’a pas ce check Lenovo, donc elle contourne le problème.
- Un bon câble USB peut éviter beaucoup de faux diagnostics.
- Rien à perdre = tout à tester. Au pire, on reflashe.
Et au pire du pire, la tablette retourne dans son tiroir. Elle a déjà huit mois d’expérience comme presse-papier.
Disclaimer d’usage : flasher un appareil comporte évidemment des risques. Vous pouvez le bricker pour de bon, perdre vos données ou juste perdre plusieurs heures à apprendre le protocole Sahara alors que fastboot fonctionnait depuis le début.
Ne copiez pas aveuglément les commandes si vous ne savez pas ce qu’elles font.
Et ne venez pas me pleurer dessus si votre tablette finit en presse-papier définitif.
Ceci dit, c’était bien marrant.
