Dumpe ta TI-Nspire CX II avec le nouveau polyDumper

[critor]

TI-Nspire CX

et

TI-Nspire CX II

commencent leur amorçage en exécutant une zone de

128 Kio

programmée dans leur puce

ASIC

: le

Boot1

sur les

TI-Nspire CX

, renommé

BootROM

sur les

TI-Nspire CX II

.

La calculatrice décompresse et exécute ensuite une ou plusieurs images programmées dans sa mémoire

Flash NAND

. Cette dernière est découpée en pages de

2 Kio

, elles-mêmes réparties en blocs de

64

pages.

Sur les

TI-Nspire CX

, la mémoire

Flash NAND

de

128 Mio

était découpée en diverses partitions. Plus précisément, la 1^ère partition comportait une table de partitions, que l'on pouvait modifier avec le programme

nsPartManagic

.

Voici la table de partitions telle qu'écrite en usine, avec dans l'ordre :

1. Manuf
   (

   1

   bloc /

   64

   pages /

   128 Kio

   )
   avec des données matérielles
2. Boot2
   (

   21

   blocs /

   1344

   pages /

   2,625 Mio

   )
   avec le
   Boot2
   précédé sur les dernières versions d'un
   Boot1.5
3. BootData
   (

   3

   blocs /

   192

   pages /

   384 Kio

   )
   avec des données de démarrage
   (contraste, mode examen, ...)
4. Diags
   (

   7

   blocs /

   448

   pages /

   896 Kio

   )
5. FileSystem
   (

   992

   blocs /

   63488

   pages /

   124 Mio

   )
   avec le système de fichiers

Pour utiliser un émulateur de

TI-Nspire CX

comme

Firebird

il était nécessaire de récupérer plusieurs de ces éléments, ce que permettait le programme

polyDumper

.

polyDumper

n'était hélas jusqu'à présent pas adapté aux

TI-Nspire CX II

.

En effet, à notre connaissance les

TI-Nspire CX II

n'ont plus de table de partitions.

Les positions et tailles des partitions sont codées en dur et dupliquées dans chaque élément en ayant besoin, c'est très sale...

Notons que cela rend quasiment impossible la réalisation d'un outil comme

nsPartManagic

permettant de déplacer et redimensionner les partitions. On peut donc supposer que

Texas Instruments

a fait exprès, même si nous ne voyons pas trop en quoi la liberté d'élargir ou réduire les différentes partitions et donc le système de fichiers serait problématique.

Sur

TI-Nspire CX II

, nous avons donc dans l'ordre telles qu'actuellement connues et documentées :

1. Manuf
   (

   1

   bloc /

   64

   pages /

   128 Kio

   )
2. BootLoader
   (

   4

   blocs /

   256

   pages /

   512 Kio

   )
   avec l'équivalent du
   Boot1.5
3. PTTData
   (

   1

   bloc /

   64

   pages /

   128 Kio

   )
   avec les données du mode examen
4. ?
   (

   1

   bloc /

   64

   pages /

   128 Kio

   )
5. DevCert
   (

   1

   bloc /

   64

   pages /

   128 Kio

   )
   avec l'éventuel certificat permettant d'installer et lancer des versions du système signées avec les clés de développement
6. OSLoader
   (

   2

   blocs /

   128

   pages /

   256 Kio

   )
   avec l'équivalent du
   Boot2
7. Installer
   (

   8

   blocs /

   512

   pages /

   1 Mio

   )
   lancé pour l'installation d'un OS nouvellement transféré
8. OtherInstaller
   (

   8

   blocs /

   512

   pages /

   1 Mio

   )
9. OSData
   (

   2

   blocs /

   128

   pages /

   256 Kio

   )
10. Diags
    (

    5

    blocs /

    320

    pages /

    640 Kio

    )
11. ?
    (

    85

    blocs /

    5440

    pages /

    10,625 Mio

    )
12. Logging
    (

    87

    bloc /

    5568

    pages /

    10,875 Mio

    )
13. FileSystem
    (

    818

    blocs /

    52352

    pages /

    102,25 Mio

    )

Les

Boot1.5

et

Boot2

qui coexistaient dans la même partition

Boot2

sur les

TI-Nspire CX

sont ici bien scindés dans 2 partitions dédiées

BootLoader

et

OSLoader

.

Plus généralement, on constate que les partitions

BootLoader

et

OSLoader

sont beaucoup plus petites que ce qu'était la partition

Boot2

.
Son équivalent ici est en fait découpé en plein de petites partitions distinctes, notamment une partition

Installer

pour l'installation d'un OS nouvellement reçu sur la calculatrice.

Avec toutes ces nouvelles partitions et la puce

NAND Flash

qui reste avec

128 Mio

de capacité, les

TI-Nspire CX II

t'offrent nettement moins d'espace de stockage que leurs prédécesseures. Le système de fichiers n'a plus une capacité de

124 Mio

mais seulement de

102,25 Mio

, soit une perte de 20%.

Aujourd'hui,

polyDumper

est enfin mis à jour dans une version gérant les

TI-Nspire CX II

!

Pendant que tu disposes de

Ndless

profites-en vite pour récupérer les images qui te seront utiles pour émuler un jour ta

TI-Nspire CX II

, lorsque

Firebird

sera prêt.

Téléchargements

:

• polyDumper
• Ndless

[Adriweb]

C'est une bonne mise a jour

Mais notons pour ceux qui veulent dumper pour emuler (la version compatible CX II de Firebird étant dispo sur github) que l'état actuel de PolyDumper n'est pas suffisant, en effet TI ayant utilisé quelques astuces pour rendre certaines parties (avec les clés il me semble) moins facilement dumpables, il va falloir attendre encore un peu pour qu'une méthode publiable soit rendu disponible par Vogtinator/Critor dans une mise à jour de PolyDumper, permettant donc de récupérer les quelques bouts restants nécessaires...

[critor]

Merci.

Rien n'empêche de commencer à récupérer les éléments, même si ils ne sont pas complets.

Actuellement, polyDumper récupère 128 Kio pour le Boot1/BootROM.
Si j'ai bien compris dans le cas des TI-Nspire CX II il manque une 2ème partie également de 128 Kio et contenant justement les clés de validation.

Je ne connais actuellement pas de méthode pour la récupérer.

Mais rien n'empêche justement nos lecteurs de chercher de leur côté, et de partager si ils trouvent un moyen.

[SlyVTT]

Salut à Tou(te)s

Juste un petit "up" pour savoir si il y a quelques avancées sur le dump complet de la CX-II et sa possible émulation dans Firebird.
J'avoue être très impatient d'avoir un émulateur fonctionnel pour le débogage du GUI Toolkit et rechercher les leaks mémoires (il y a tellement de pointeurs et d'allocations dynamiques que c'est chaud patate à rendre tout propre à la fin d'un "run").
Mes compétences en codage hardware étant vraiment naze (faut être conscient de ses limites ), je peux pas trop aider sur le sujet mais je suis de tout cœur avec les costauds qui ont les mains dans le cambouis

Ciao

Sly

[critor]

Rien de nouveau de mon côté, désolé. Très embêtant de développer des programmes Ndless spécifiques à la TI-Nspire CX II

(utilitaires notamment)

sans émulateur.

J'ignore si il y a une manipulation logicielle ou matérielle permettant de

mapper

en mémoire la moitié manquante/protégée du Boot ROM

(équivalent du Boot1 des anciens modèles)

.

[SlyVTT]

Pas de soucis.

En effet c'est un peu chaud de développer sans debugger. Bon quand ça plante direct, on voit vite qu'il y a un problème, mais par contre si ça marche, on est malgré tout pas sûr que le code soit nickel.

On peut passer par des logs pour les programmes graphiques, mais c'est tout de même la plaie à regarder par la suite

Soyons patients, ça viendra.

A plus

Sly

[parisse]

Il faudrait que vous puissiez mettre la main sur une rom de nspire cx, comme ca vous pourriez debugguer avec firebird ce qui permet d'aller 100 fois plus vite je dirais (c'est comme ca que je fais pour porter KhiCAS sur Nspire).
Les executables sont compatibles entre CX et CX II.

[SlyVTT]

Oui en effet je pense faire ça, je vais regarder si je trouve une ROM de CX qq part.
Ca pourrait aider un peu.
A plus

Sly