Forum TI-Planet.org

Ma calculette étant arrivée (contrairement à mes nièces pour le moment), j'en ai profité pour désosser mon HP Prime G2 et faire quelques tests préliminaires. Mes observations pour le moment:

• Le couvercle du compartiment de la batterie est un très bon outil pour enlever la coque inférieure sans l'endommager.
• Comme avec la G1, il y a une feuille de cuivre collé à la coque pour limiter les émissions électro-magnétiques et un film adhésif collé au PCB empêche tout contact. J'ai décollé le film pour l'appliquer directement sur la feuille de cuivre afin qu'il ne m'embête plus, en retaillant au cutter/ciseau au besoin.
• Je n'ai pas trouvé d'UART sur les tests points pour le moment, ou plus précisément je n'ai pas trouvé de logs par UART après un reset.
• Appliquer une tension de 3,3V sur TP907 lors d'un reset active le Serial Downloader par USB, qui est le recovery des puces iMX (TP907 serait donc le pin BOOT_MODE1).

J'ai également regardé le fichier de mise à jour, il semble contenir une image brute à destination de la NAND. Le fichier contient un IVT à l'offset 0x400 ainsi qu'un DCD à destination du bootloader en ROM, mais pas de CSF requis pour le High-Assurance Boot. En d'autres termes, la calculette ne semble pas verrouillée au niveau du SoC à priori.

Ca fait plein de bonnes nouvelles, tout ça

Je crois que mon programme de dissection des updates de Prime G2 n'a pas bougé depuis viewtopic.php?f=55&t=21758&start=20#p234397 , mais il faudrait que je vérifie.

En grattant un peu plus, je me suis rendu compte que l'image firmware semble être une image brute de la NAND préfixée par 24 octets. Le mode Serial Download du SoC a l'air d'accepter et de "lancer" une image U-Boot i.MX6ULL pour le kit d'évaluation à travers mfgtools.

Maintenant les mauvaises nouvelles : je n'ai toujours pas trouvé d'UART, donc je n'ai aucun moyen de savoir ce qu'il se passe. Ça commence à devenir gênant, d'autant plus qu'attaquer la calculette avec des payload assembleur faits à la main comme à l'époque de la G1 va être compliqué car on n'aura pas une couche préalable initialisant un minimum le matériel si on exécute à travers le recovery de NXP...

En résumé : je botte en touche et je ne suis pas outillé ni suffisamment compétent pour une approche frontale ce coup-ci. Je vais probablement me rabattre sur le reverse-engineering du firmware d'HP en attendant de trouver mieux, mais je redoute le syndrome du binaire monobloc indigeste...

En tous cas, félicitations pour ta superbe acquisition !

A priori, je ne t'ai pas envoyé de fichier IDC du bootloader. Tu confirmes ?
On avait parlé de radare2 + cutter, mais pour l'instant, ça ne semble ni être au niveau de fonctionnalité, ni surtout au niveau de stabilité adéquat. J'ai assisté au workshop r2 à GreHack (ça n'était pas mon premier choix, mais l'autre était déjà largement booké), et des discussions m'ont donné des éléments sur le manque de stabilité du framework, même s'il finira par se résoudre: les contributeurs sont nombreux.

Je n'ai rien reçu, non.

Le bootloader de la calculette G1 se laissait assez bien disséquer avec objdump à l'ancienne vu sa taille modeste, mais cette approche n'est pas une option ici. Je n'ai pas encore étudié la question pour savoir quel outil pourrait prendre la relève (après tout, rien ne m'empêche de complètement craquer et d'écrire mon propre outil de reverse-engineering basé sur LLVM tel un bon bourrin savoyard...).

Bon, vu que radare2 avec Cutter n'est pas très coopératif sur ce projet et que je suis malade depuis une semaine (ça n'aide pas à la réflexion), j'ai décidé de regarder si le PCB était plus vert de l'autre côté.



Étonnamment, la calculette fonctionne encore alors que j'ai dû séparer ce PCB d'une plaque métallique avec un mélange d'Opinel, de spatule et de papier. Le film adhésif reliant les deux est très coriace, je ne recommande vraiment pas de tenter une telle manipulation à ceux qui tiennent à leur HP Prime...

De ce côté, il y a des tests points pour plein de choses intéressantes et notamment du JTAG, UART, SD... Je ne suis pas équipé pour faire du JTAG et l'UART reste muet avec le firmware officiel. La tentative de chargement d'u-boot pour la carte d'évaluation de l'i.MX6ULL à travers le recovery du SoC n'a rien donné non plus sur UART1_TX. Je vais probablement essayer de croiser ce PCB avec la carte d'évaluation ainsi que la datasheet du SoC pour mapper cette forêt vierge.

Merci de nous avoir immortalisé la face cachée.

Tiens, j'ai apparemment raté l'envoi de mon post...
En effet, bon travail

Sur le modèle commercial, les conditions réglementaires d'utilisation des calculatrices étant hélas ce qu'elles sont, ça se comprend que ces nombreux test points permettant d'accéder à des capacités matérielles bas niveau soient accessibles uniquement sur la face cachée du PCB.

Je me suis commandé un adaptateur JTAG, il devrait arriver la semaine prochaine.

Je pense qu'ils ont laissé le JTAG et l'UART au dos car le recovery du SoC permet de débricker la calculette par USB en toutes circonstances (d'où le test point pour le déclencher sur le côté exposé). Les HP Prime G1 n'avaient pas cette possibilité, donc une NAND corrompue au mauvais endroit nécessitait l'emploi du JTAG pour réparer la calculette, donc ces pads étaient exposés. Il est vrai que l'accès au JTAG pourrait aider à la création d'un PTT-killer dans l'absolu (même si ça reste un exercice a priori très difficile), mais je pencherais plutôt sur le fait que tous les test points situés à l'arrière ne sont pas utilisés une fois la carte électronique testée dans la chaîne de production (a contrario, les test points situés sur la face exposé sont probablement tous ou presque utiles pour au moins diagnostiquer des pannes matérielles).

Après tout, contrairement à la NumWorks cette calculette n'est pas conçue pour être bidouillée par l'utilisateur et HP doit disposer en interne de prototypes ou de cartes d'évaluation i.MX6ULL dédiées au développement s'ils ont besoin de sortir le JTAG pour faire du debug de problèmes obscurs sur cible.