[mOved] TI-Nspire, premières impressions - Page 6

Mes sources ? Ben ton wiki!
Section Hardware ^^'

OK c'est dans le PDF du zevio

(Tu m'a fait mourrir de rire )

Mais bon, je crois que sur ce wiki il ne faut mettre que ce dont on est sûr sinon ca va finir... ^^' lol
Donc ce que l'on sait de ce proc :
C'est LSI qui l'a fait (Zevio 1020), basé sur un ARM ARM926EJ-S.

Apres, le datasheet que j'ai donné, c'est celui de l'ARM. Donc attention
Comme je l'ai dit, je sais pas ce que LSI a retouché (ou non) sur le proc original

Dude (./147) :
bloo ou ExtendeD > Y a-t-il un ecran où on peut voir l'occupation de la mémoire ? Si oui, est-ce comme sur les 68k où l'on pouvait voir la place que prennait le systeme ?

Voir snapshot.

squalyl (./138) :
EDIT: c'est quoi ce connecteur noir avec des ressorts dorés en haut?
http://www.unsads.com/~squalyl/nspire/pics/nspire003.jpg

C'est le connecteur du clavier !

ah, ok, et donc celui du bas qui ressemble à une cartouche de jeu vidéo c'est quoi?

squalyl (./155) :
ah, ok, et donc celui du bas qui ressemble à une cartouche de jeu vidéo c'est quoi?

Bonne question ! c'est celui qui est caché par la clapet coulissant à ressort (voir photos sur mon site). Je n'ai aucune info dessus. Je ne sais plus qui ici, a supposé qu'il servait pour la vidéoproj. On dirait un connecteur pour un dock, genre Ipod.

bloo (./156) :
On dirait un connecteur pour un dock, genre Ipod.

C'est vrai, je vois pas comment un connecteur tiendrait tout seul sinon.

squalyl (./150) :
Elle est intégrée et fait partie de l'architecture. MAIS de toute façon c'est comme sur les autres CPU, un MMU ça se désactive par un bit de registre quand on est en mode superviseur.

Dude, quelles sont tes sources pour affirmer que la nspire contient bien un zevio 1020 ? (pas pour te contredire mais pour être au courant quoi)

Il y a ZEVIO d'écrit sur le CI. Donc on ne sait pas si c'est le 1020 ou un autre.
Je ne pense pas que tous les blocs décrits dans le PDF de lsi logic soient là (le DSP, le contrôleur 3D, ...), mais à priori c'est un ARM9, donc il y a une MMU (même si elle n'est pas forcément utilisée)

Je sais.

mais va voir le site de LSI, y'a pas 50 zevios, ou alors j'ai mal cherché.
c'est le nom du SoC en fait.

squalyl (./155) :
ah, ok, et donc celui du bas qui ressemble à une cartouche de jeu vidéo c'est quoi?

Plusieurs broches sont directement reliées au ZEVIO.
Il y a peut-être le JTAG dessus, pour la programmation à la fabrication.
Le souci, c'est de les trouver à l'aveugle, sans avoir le brochage du ZEVIO.

Le zevio est aussi utilisé dans une console de jeux : http://multimedia.cx/eggs/vflash/
J'ai envoyé un mail à l'auteur du blog, demandant si il pouvait prendre des photos du PCB. On pourrait peut-être déduire les broches du JTAG en observant les similitudes.

pourquoi pas

squalyl (./159) :
mais va voir le site de LSI, y'a pas 50 zevios, ou alors j'ai mal cherché. c'est le nom du SoC en fait.

Ce n'est pas parce que le site de LSI LOGIC n'en présente qu'un seul qu'il n'en existe pas d'autres. Sinon pourquoi l'appeler le 1020, si ce n'est pas pour le différentier d'un autre modèle de ZEVIO ?
Le boitier (QFP208) correspond avec celui du PDF, mais pas avec le site qui montre un BGA en photo.

Concernant les descripteurs USB :

En mode Nspire (les parties intéressantes, i.e. qui diffèrent de la Titanium et de la 84+) :

Device Descriptor:
	idProduct	E012h (pour rappel e001 : Silverlink, e004 : Titanium, e008 : 84+)
	bcdDevice	0100h // 1.00
	iProduct	  02h // "TI-Nspire(tm) Handheld"

Configuration Descriptor:
	bmAttributes	  80h // Bus Powered (Titanium : Self Powered Remote Wakeup)
	bMaxPower	  32h // 100 mA (Titanium : 0 mA)

OTG Descriptor // Comme sur Titanium et 84+

Une interface de classe Vendor Specific avec 1 Bulk in et 2 Bulk out (au lieu de 1 in et 1 out sur Titanium/84+).

En mode 84+ émulée, comme ceux de la 84+ réelle sauf :

Device Descriptor:
	idProduct	E004h // Titanium !
	bcdDevice	0200h // 2.00 - 84+ réelle : 1.10
	iProduct	  02h // "TI-84 Plus Silver Edition (Emulation)"

Configuration Descriptor:
	bmAttributes	  C0h // Self Powered - Comme 84+
	bMaxPower	  00h // 0 mA

Les descripteurs utilisés n'est pas celui de la ROM 84+ embarquée, ils proviennent de la Nspire. Il n'y aurait peut-être pas du tout d'émulation d'USB finalement...

tiens voila pourquoi tilp la voit comme une titanium. On pourrait pas corriger tilp avec ça justement? (0xE004/0x0200 => 84+nspire)

Oui je me demandais, je vais demander à Roms s'il a le temps (à moins que quelq'un veuille bien me faire un build).

ExtendeD (./163) :
l n'y aurait peut-être pas du tout d'émulation d'USB finalement...

Mmm j'ai un doute : si j'y branche une souris optique, elle clignotte dans un mode comme dans l'autre... mais beaucoup plus lentement en 84+ (1s de lumière au lieu de ~0,2s).

Il y a une différence significative dans les taux de transfert entre le mode 84+ émulé et le mode nspire ?

Build pour quel target? i386-pc-mingw32?

faudrait implémenter la détection déja

Tu penses qu'en 8mn Kevin n'a pas largement eu le temps de le faire ?

Virer la vérification du modèle devrait être suffisant pour tester. (On peut choisir le modèle manuellement.)

Kevin Kofler (./167) :
Build pour quel target? i386-pc-mingw32?

Oui

PpHd (./166) :
Il y a une différence significative dans les taux de transfert entre le mode 84+ émulé et le mode nspire ?

Tout ce qu'on peut faire c'est comparer de l'USB Nspire avec de l'i/o 84+ émulé. Tu voulais voir quoi ?

Tiens, pour l'occupation de la mémoire flash, le calcul se fait tout seul : 2048ko pour l'émulation de la flash de la 84+, 671ko de fichiers standard zippés (qu'on retrouvent dans le TNO), 3020ko de TNO (gardé tel quel pour un flashage Nspire à Nspire), 97,8ko de boot code et certificats (ou de je sais pas quoi s'ils sont plutôt stockés sur la NOR) = ... 5,7Mo d'occupation système affichés par l'OS après un reset ^^

En mode 84+ émulée, les flash apps standard peuvent être supprimées, ça ne modifie l'occupation visible en mode Nspire (donc tout ça est probablement stocké directement sous forme d'image de 2Mo dans le FS Nspire).

si ils font une émulation correcte, oué, c'est logique

y'a un explorateur de fichiers?

Un explorateur de classeurs. Tous les autres fichiers qu'on voit dans le TNO sont cachés.

Bon, j'ai regardé le code de TiLP et libticables2, et je n'ai rien trouvé qui empêcherait de forcer le mode TI-84+ dans les options même si le PID est celui d'une Titanium.

donc on connecte la calc, et après on choisit "TI84+" dans setup/comm et on reteste

ExtendeD (./172) :
Tiens, pour l'occupation de la mémoire flash, le calcul se fait tout seul : 2048ko pour l'émulation de la flash de la 84+, 671ko de fichiers standard zippés (qu'on retrouvent dans le TNO), 3020ko de TNO (gardé tel quel pour un flashage Nspire à Nspire), 97,8ko de boot code et certificats (ou de je sais pas quoi s'ils sont plutôt stockés sur la NOR) = ... 5,7Mo d'occupation système affichés par l'OS après un reset ^^

En mode 84+ émulée, les flash apps standard peuvent être supprimées, ça ne modifie l'occupation visible en mode Nspire (donc tout ça est probablement stocké directement sous forme d'image de 2Mo dans le FS Nspire).

Si c'est ça, la calc lirait la partie cryptée du TNO (au fur et à mesure, ou entièrement au démarrage). Pourquoi est-ce que ce serait différent pour les fichiers zippés ?

squalyl (./176) :
donc on connecte la calc, et après on choisit "TI84+" dans setup/comm et on reteste

De mémoire ça a pas marché. Je resterai avec des logs.

hwti (./177) :
Si c'est ça, la calc lirait la partie cryptée du TNO (au fur et à mesure, ou entièrement au démarrage). Pourquoi est-ce que ce serait différent pour les fichiers zippés ?

C'est vrai que l'OS met un certain temps à démarrer après reset ou changement de clavier avec "Loading OS System" et "Loading Filesystem" comme messages.
Donc plutôt pas de TNO gardé tel quel, mais décompressé/décrypté au démarrage en RAM. Le FS serait aussi plutôt dézippé (2363ko) et garder en RAM (ou en Flash ?)

C'est vraiment frustrant tous ces manques