[Pipo m9pro] ne démarre plus

[nicoVI]

                            bonjour,

alors tout d'abord, mon pc tourne sous debian gnu linux.
ma tablette est une pipo m9pro et suite à un mauvais flash , elle ne fonctionne plus mais j'ai toujours une com usb .
lorsque je connecte ma tablette, les message du noyaux m'indique :

# dmesg
[59205.604202] usb 3-2: new high-speed USB device number 4 using xhci_hcd
[59205.622250] usb 3-2: unable to get BOS descriptor
[59205.623754] usb 3-2: New USB device found, idVendor=2207, idProduct=310b
[59205.623761] usb 3-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0

ensuite j'ai un fichier avec les règles suivante :
# cat /etc/udev/rules.d/99-android.rules
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2207", ATTRS{idProduct}=="310b", MODE="0660", OWNER="root"

et un autre:
# cat ~/.android/adb_usb.ini
0x2207

mais adb ne fonctionne pas :
# adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached

# adb reboot
error: device not found
#

normalement adb est sencé affiché le numéro de séries après le device attached mais le miens vaux maintenant 0 de même pour mfr et product .
alors d'après vous puis-je espérer retrouver un système fonctionnel ?
je vous en remercie d'avance

à+

Modifié 22 janvier 2014 par nicoVI

[zrt22]

Bonjour,
Merci de commencer par mettre le titre du sujet au format indiqué dans : >>>>>>>> A LIRE AVANT DE POSTER <<<<<<<<. La façon de le faire y est indiquée.

[nicoVI]

oups titre modifié

 

bon apparament ma tablette est bien reconnue en mode debug :

 

# lsusb -v

Bus 003 Device 005: ID 2207:310b  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.01
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x2207
  idProduct          0x310b
  bcdDevice            1.00
  iManufacturer           0
  iProduct                0
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              400mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      6
      bInterfaceProtocol      5
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Status:     0x19f0
  (Bus Powered)
  Debug Mode

 

je devrais peut-être remettre en cause adb fastboot ..

[Lannig]

Puisque je parle à un Linuxien, visiblement : le démon adbd qui gère coté tablette les comms USB avec le protocole ADB et donc présente au PC le périphérique USB correspondant est lancé assez tôt dans le boot, mais quand même après le démarrage du kernel et quelques étapes de l'init.

Si la tablette n'atteint plus ce stade-là, ce n'est pas ce périphérique qui sera présenté au PC, mais un autre (fastboot, voire les périphériques présentées par les tablettes depuis leur bootloader primaire en ROM interne au SOC p.ex. le mode FEL sur les tablettes Allwinner).

Ce que je veux dire, c'est que ce n'est pas parce que ton PC détecte un périphérique USB que c'est celui qui est utilisable par ADB.

En pratique, tout semble indiquer que la tablette ne démarre plus au point de lancer adbd...

[Lannig]

Mon hypothèse est confirmée en faisant une recherche sur VID_2207  PID_310B.

On tombe par exemple sur cette page : https://www.miniand.com/wiki/Restoring+the+iFive+X2s+recovery+partition

qui dit : 

 

[DEVICE_ID]

  VID=2207

  PID=310B

 

These are the vendor and product IDs of the RK3188 in flash mode.

Donc la tablette ne "boote" plus du tout Android. Elle n'a plus de système et se met en flash mode pour qu'on lui flashe un nouveau firmware.

[nicoVI]

merci Lannig, ce que tu as dit m'a beaucoup aidé à y voir plus claire et j'ai pue approfondir mes recherches.

donc j'ai essayer de la flasher avec une rom android mais lorsque je fais "fastboot flash boot boot.img" il me met <waiting for device> indéfiniment ... alors en cherchant un peu j'ai trouver un petit programme en c à compiler ici http://www.arctablet.com/blog/forum/firmware-development/dumping-firmware-on-arnova-g2-arnova-g3-and-other-rockchip-based-tablets/ et il dit de mettre cette ligne : if (!(h = libusb_open_device_with_vid_pid(c, 0x2207, 0x310b))) pour mon chipset rk3188 ce qui coorespond à mon vid et pid . il compile bien . il y à plus qu'à tester dés que ma tablette si capricieuse voudra se connecter.

Modifié 23 janvier 2014 par nicoVI

[nicoVI]

bon, j'ai réussi à flasher la rom avec rkflashtool en suivant mon fichier parameter :

FIRMWARE_VER:4.1.1^M
MACHINE_MODEL:M9pro^M
MACHINE_ID:007^M
MANUFACTURER:RK30SDK^M
MAGIC: 0x5041524B^M
ATAG: 0x60000800^M
MACHINE: 3066^M
CHECK_MASK: 0x80^M
KERNEL_IMG: 0x60408000^M
#RECOVER_KEY: 1,1,0,20,0^M
CMDLINE:console=ttyFIQ0 androidboot.console=ttyFIQ0 init=/init 
initrd=0x62000000,0x00800000 mtdparts=rk29xxnand:0x00002000@0x00002000(misc),
0x00006000@0x00004000(kernel),
0x00006000@0x0000A000(boot),
0x00010000@0x00010000(recovery),
0x00020000@0x00020000(backup),
0x00040000@0x00040000(cache),
0x00800000@0x00080000(userdata),
0x00002000@0x00880000(kpanic),
0x0012C000@0x00882000(system),
-@0x009AE000(user)^M

ce fichier est situer au tout début , entre 0x0000 et 0x2000 donc voici mon script :

./rkflashtool w 0x0000 0x2000 < parameter
sleep 1
./rkflashtool w 0x00002000 0x00002000 < misc.img
sleep 1
./rkflashtool w 0x00006000 0x00004000 < kernel.img
sleep 1
./rkflashtool w 0x00006000 0x0000A000 < boot.img
sleep 1
./rkflashtool w 0x00010000 0x00010000 < recovery.img
sleep 1
./rkflashtool w 0x0012C000 0x00882000 < system.img

normalement le fichier parameter indique au système où ce situe tout ce dont il a besoin pour fonctionner mais il manque un fichier éssentiel, le bootloader . le mien s'appel RK3188Loader(L)_V1.24.bin  et je ne sais pas où le mettre ... et je n' est pas de fichier initrd pourtant initrd sert à crée de l'espace en ram pour charger le noyaux . donc je serais tenter de mettre le bootloader à la place de initrd mais j'ai peur de faire une bêtise. si quelqu'un pouvais infirmé ou confirmé mon intuition..

merci beaucoup

Modifié 24 janvier 2014 par nicoVI

[_ATP_]

Bonjour :

 

Alors, première chose : le binaire rkflashtool à jour est disponible sur sourceforge.net.

http://sourceforge.net/p/rkflashtool/Git/ci/master/tree/ <= cliquez sur le bouton  [download], décompressez et lire le fichier README.

Je donne le dépôt GIT, car dans l'archive 5.1, il manque un fichier, le 'version.h'.

----

Ensuite, dans ton script, il y a une légère erreur - mais qui a son importance :

./rkflashtoll w 0x0000 0x2000 < parameter

Qui devient :

./rkflashtool w 0x0000 0x2000 < parameter

----

Pour finir, histoire d'être sûr que tu comprennes bien le propos :

Quand ta tablette est allumée, et connectée en USB, avec le mode debogage USB actif, elle est détecté par le sous-système lsusb, ainsi :

$ lsusb | egrep '2207'
Bus 002 Device 026: ID 2207:0010  

La commande 'adb devices' fonctionnera, si tout est paramétré correctement, càd fichier .android/adb_usb.ini et le fichier udev ...

$ adb devices
List of devices attached 
WAWJM5UMUW	device

Quand tu la rebootes en mode bootloader - appelée aussi fastboot sur les phones android - elle est détecté en tant que PID : 310b :

$ adb reboot-bootloader
$ lsusb | egrep '2207'
Bus 002 Device 027: ID 2207:310b  
$ fastboot devices

Mais fastboot n'indique rien, et quand tu chercheras un injecter un bootloader avec, tu seras en attente de périphérique !

Et, pourquoi fastboot ne fonctionne pas ?! Pour l'instant, je n'ai pas de réponse, justement j'aimerais trouver et comprendre !

Ce qui est dommage parce qu'il suffirait de faire un 'fastboot flash bootloader RKLoader*.bin' ...

---

Donc, il faut utiliser les outils 'rkflashtool' et 'rktool' <= si besoin de flasher une ROM officielle.

(je suis entrain de créer script bash + zenity pour assister.)

À savoir que pour flasher nos médiums RK, il existe une GUI - interface graphique : rkflashkit. Mais cet outil ne permet ni de flasher le fichier 'parameter', ni le binaire 'RKLoader*.bin'.

---

Quant à savoir pour l'instant, comment injecter le binaire 'RKLoader*.bin', sous Linux, je ne sais pas - mais ta réflexion de initrd est intéressante ... Oui ? non ?

Ce qui est sûr, c'est que l'outil 'RKAndroidTools' que l'on retrouve dans les ROM Customs de Riley et Finless (du site Freaktab) flashe ce binaire ; mais c'est sous Windows.

---

Je suis récemment "tombé" sur un log irc du site 'linux.rockchip.info' - si je ne me trompe pas - dont un des gars disait, en juillet 2013, que ce n'était pas possible de flasher le binaire RKLoader avec rkflashtool ... de l'époque !

(faut que je retrouve ce log ...)

---

 

Voili, voilou, tu sais tout ! :D

 

 

 

[Lannig]

Quand tu la rebootes en mode bootloader - appelée aussi fastboot sur les phones android - elle est détecté en tant que PID : 310b :

$ adb reboot-bootloader
$ lsusb | egrep '2207'
Bus 002 Device 027: ID 2207:310b  
$ fastboot devices

Mais fastboot n'indique rien, et quand tu chercheras un injecter un bootloader avec, tu seras en attente de périphérique !

Et, pourquoi fastboot ne fonctionne pas ?! Pour l'instant, je n'ai pas de réponse, justement j'aimerais trouver et comprendre !

Ce qui est dommage parce qu'il suffirait de faire un 'fastboot flash bootloader RKLoader*.bin' ...

Parce que ce n'est pas un mode fastboot.

Le mode fastboot est géré par un bootloader, première étape de ce qui est chargé depuis la flash. Il n'existe d'ailleurs pas sur tous les terminaux Android, loin de là (et à ma connaissance pas sur les tablettes Rockchip).

Ce que tu vois s'appelle le "flash mode" sur Rockchip et "FEL mode" chez Allwinner. C'est un mode géré par de la ROM (de la vraie ROM, non altérable) qui est à l'intérieur du SOC.

Dans ce mode, seul les outils propriétaires du fondeur du SOC (Rockchip, Allwinner) ou des outils qui ont été "reverse engineerés" (RkAndroidTool) peuvent gérer le protocole utilisé sur la connexion USB.

Les outils génériques du SDK Android (fastboot) ne "causent" pas le même langage.

En fait le protocole fastboot n'est qu'une version  modifiée du protocole ADB.

[_ATP_]

Parce que ce n'est pas un mode fastboot.

Le mode fastboot est géré par un bootloader, première étape de ce qui est chargé depuis la flash. Il n'existe d'ailleurs pas sur tous les terminaux Android, loin de là (et à ma connaissance pas sur les tablettes Rockchip).

Ce que tu vois s'appelle le "flash mode" sur Rockchip et "FEL mode" chez Allwinner. C'est un mode géré par de la ROM (de la vraie ROM, non altérable) qui est à l'intérieur du SOC.

Dans ce mode, seul les outils propriétaires du fondeur du SOC (Rockchip, Allwinner) ou des outils qui ont été "reverse engineerés" (RkAndroidTool) peuvent gérer le protocole utilisé sur la connexion USB.

(....)

 

Merci Lannig.

Néanmoins des informations que j'obtiens du coté de linux-rockchip.info :

 

there are 2 modes for USB communication.

mask rom mode, like as FEL mode on sunxi, bootloader needs to be loaded

by rockchip official tools such as RKAndroidTool, RKBatchTool, etc.

rkflash/rkflashtool doesn't support this mode yet.

bootloader mode, bootloader(currently made by rockchip only) is loaded

from flash or USB, it should be possible to read/write RAM, NAND and

IDB(bootloader) via USB. rkflashtool can read/write NAND and can read

RAM/IDB for now.

 

Quand je redémarre ma tablette avec 'adb reboot-bootloader', c'est bien dans le mode bootloader ... le seul dans lequel est, pour l'instant, capable de lire et écrire l'outil rkflashtool ... la différence - que tu précises - est que des softs comme RKAndroidTool sont capables de redémarrer dans le fameux mode "mask rom".

Et, je suis prêt à parier que ce mode libére le bootloader et permet donc son écriture !

 

Le meilleur dans l'histoire - faut que je retrouve cet autre log - est qu’apparemment, en interne chez Rockchip, ils utilisent des outils sous Linux, pour faire ce que font RKAndroidTool et consort ... tsss !

 

Pour info, je centralise toutes les informations que je trouve sur tablette-chinoise.net ;-)

 

----

 

Quand nicoVI écrit, et pense :

 

 

je serais tenter de mettre le bootloader à la place de initrd mais j'ai peur de faire une bêtise. si quelqu'un pouvais infirmé ou confirmé mon intuition..

 

 

Son intuition est apparemment bonne : - (cf log irc linux-rockchip.info du 11/12/2013) :

 

20:45 <ncrmnt> and don't remove 'initrd=...' from there - it screws thing up for the bootloader

 

Sauf que dans l'état des outils disponibles sous Linux, nous n'y arriverons pas ...

 

----

 

D'autant qu'il manque aussi l'étape de gestion de l'effacement de l'IDB, nommé 'Erase NAND (IDB)' dans RKAndroidTool.

 

Et, pourtant Steve, l'auteur du script perl nommé 'rksp', utilisable sous Linux a écrit les deux procédures suivantes :

########################################################################
# Erase IDB & write parameters
########################################################################
sub eraseIDB(){
my $i=0;
my $eraseIDB = "/tmp/eraseIDB".$$;
my $FF=chr(255) x 512;
  open(TABLET,">$eraseIDB");
  for($i=0;$i<8192;$i++){
    syswrite TABLET,$FF,512;
  }
  close TABLET;
  print "Erase IDB ...\n";
  writeflash(0x00,0x2000,$eraseIDB);
  unlink $eraseIDB;
}



########################################################################
# Write IDB with parameter file crc by rkcrc
########################################################################
sub writeIDB(){
  print "Write parameters ...\n";
  writeflash(0x00,0x20,"parameters");
  writeflash(0x20,0x20,"parameters");
  writeflash(0x40,0x20,"parameters");
  writeflash(0x60,0x20,"parameters");
  writeflash(0x80,0x20,"parameters");
}

Sa procédure 'eraseIDB' me semble correspondre à ce que peut faire rkflashtool :

rkflashtool e offset size             erase flash (fill with 0xff)

Mais je ne suis pas assez calé pour l'affirmer - j'ai d'ailleurs écrit à Steve, en attente de réponse, et j'espère qu'il m'apportera sa vision des choses.

Parce que générait un fichier paramater crc n'est pas bien difficile ... ni l'injecter par rkflashtool ;-)

 

@lannig : Kuan me tanne pour que je te contact ... histoire que tu m'aides à avancer ;-)

[Lannig]

Je pense que ce que Linux-Rockchip.info appelle mode bootloader n'est pas ce que Google appelle le mode fastboot et qui est supporté par les outils du SDK.

Ce mode bootloader est propriétaire à Rockchip aussi et ne cause qu'avec les outils Rockchip.

Ce que j'ignorais effectivement c'est qu'il est différent du flash mode.

 

@lannig : Kuan me tanne pour que je te contact ... histoire que tu m'aides à avancer ;-)

Comprends pas. Explique-moi ça dans un MP STP.

[nicoVI]

ma tablette est officiellement débriqué !!

alors éffectivement je n'y suis pas arrivé sous linux alors j'ai installé windows dans une machine virtuel . ensuite j'ai téléchargé ceci : http://www.freaktab.com/showthread.php?8310-Pipo-M9-Pro-RileyROM-2-1 , il y a les drivers , l'outil "Rom_Flash_tool.exe" et ça a marché . ma tablette refonctionne comme au premier jour. j'avoue avoir eue peur en voyant partout sur le net "briqué = poubelle" , et la connexion usb qui marchait une fois sur 20 avec des messages du noyaux qui disaient un truc comme " device not accepting address 69, error -71" ou parfois rien du tout .

alors j'espère que ceci rassurera certaines personnes dans la même situation que moi et qu'il pourront y voir une solution. en tout cas moi plus jamais je l'a flash, même pour une super rom qui sait tout faire .

et je vous remerci beaucoup pour votre aide qui m'a été très utile .

[_ATP_]

ma tablette est officiellement débriqué !!

alors éffectivement je n'y suis pas arrivé sous linux alors j'ai installé windows dans une machine virtuel . ensuite j'ai téléchargé ceci : http://www.freaktab.com/showthread.php?8310-Pipo-M9-Pro-RileyROM-2-1 , il y a les drivers , l'outil "Rom_Flash_tool.exe" et ça a marché . ma tablette refonctionne comme au premier jour. j'avoue avoir eue peur en voyant partout sur le net "briqué = poubelle" , et la connexion usb qui marchait une fois sur 20 avec des messages du noyaux qui disaient un truc comme " device not accepting address 69, error -71" ou parfois rien du tout .

alors j'espère que ceci rassurera certaines personnes dans la même situation que moi et qu'il pourront y voir une solution. en tout cas moi plus jamais je l'a flash, même pour une super rom qui sait tout faire .

et je vous remerci beaucoup pour votre aide qui m'a été très utile .

 

Oui, excuse-moi, j'aurais pu te le dire de récupérer RKAndroidTools.exe et de la flasher à nouveau depuis Windows.

Apparemment, pour ton info, non les Rockchip ne sont pas "brickable", donc pas poubelle !

 

Quant à ne jamais plus la flasher ... ce n'est pas la bonne réaction. Mais bon ... bon courage !

D'autant que les ROM Riley et Finless améliorent la fluidité, et l'usage de nos tablettes PIPO ! ;-)

 

@Lannig: j'ai un problème, quand je réédite des messages sur le forum, j'ai ce message d'erreur :

TypeError: ipb.textEditor.getEditor(...) is undefined

[Lannig]

@ATP:MIUI : je suis modérateur, pas administrateur :)

Poste un message dans "Votre FrAndroid" en donnant tous les détails (navigateur etc.) et en précisant si c'est une erreur venant du navigateur (popup) ou bien du forum. Ça sera transmis aux admins.