Forum TI-Planet.org

Dans une news précédente, nous découvrions et récupérions pour vous sur un prototype Nspire un OS encore inconnu à ce jour, le 1.4.8092.


Mais peut-être ne l'aviez vous pas remarqué? Il s'agit en fait d'un OS Nspire fort spécial comme nous n'en avions encore jamais récupéré.

Oui, il s'agit en effet d'un OS de debug, comme le mentionne son numéro de version complet "1.4.8092 debug".

Jusqu'à présent, la plupart des prototypes que nous récupérions disposaient d'OS relativement stables et proches des versions finales. Ils avaient été prêtés/confiés à des enseignants/étudiants afin de tester la TI-Nspire avant son lancement pour la rentrée 2007.



Mais ici c'est un prototype fort particulier issu directement de l'équipe de développement TI-Nspire!
Il est exceptionnel d'en récupérer, puisque les prototypes produits et utilisés en interne chez TI sont normalement destinés à la destruction une fois qu'ils ne servent plus.

Qu'est-ce que cet OS a donc de particulier?
Et bien il crée un fichier de debug "/documents/navnet.log.csv" et y enregistre nombre d'informations sur le fonctionnement du protocole de communication NavNet, messages que l'on retrouve également sur la console série RS232 préfixés de "[64]".

Voici par exemple le bootlog du démarrage de cet OS, ou vous remarquerez plusieurs de ces messages:

Code: Select all

Beginning system initialization.
Preparing file system. This takes a while...
   POSIX layer initialized.
   POSIX devices initialized.
Datalight Reliance v2.10.1150
Copyright (c) 2003-2006 Datalight, Inc.
Datalight FlashFX Pro v3.00 Build 1358
Nucleus Edition for ARM9
Copyright (c) 1993-2006 Datalight, Inc.
Patents: US#5860082, US#6260156.

   POSIX file system initialized.
File system ready.
* P1R2 mode battery door detection
System build date: May 13 2008, 23:30:55
Available memory: 18624748 bytes
Purging temporary files...
Launching system...
Setting log file to /documents/navnet.log.csv with a buffer of 4096 bytes
Setting Console Log Level = 3
RET - Echo UDP: TI_Echo_UDP_Init called +++
RET - ECHO UDP: We created Socket ID Successful. SocketID = 1
RET - ECHO UDP: TI_UDP_Echo_BindIPAddr +++
RET - ECHO UDP: NU_Bind Successful
RET - ECHO UDP: TI_UDP_Echo_BindIPAddr ---
RET - ECHO UDP: EchoUDPListenerThread. Inside Thread +++
RET - ECHO UDP: Init called ---
[64] Register UDP stream connector, result=0
[64] TI_NN_Init Called. LowAPI LowAPI LowAPI 02-06-2008
[64] CM: init_conn_mgr: entered (NavStack: connection manager: 1/31/2008).
[59] CM: processLocalNodeRecvDeferredQueue: entered (NavStack: stream manager:
/22/2008).

[64] Entered TI_NN_StartService. Service Id: 5000 +++
[64] Start service: port 5000, '.NS_SVC.5000' service.
[64] End of TI_NN_StartService. Service 5000 started. ---
[64] Start sync service
[64] Entered TI_NN_StartService. Service Id: 4060 +++
[64] Start service: port 4060, '.NS_SVC.4060' service.
[64] End of TI_NN_StartService. Service 4060 started. ---
[64] MS: MessageServiceRegister called.
[64] Entered TI_NN_StartService. Service Id: 4051 +++
[64] Start service: port 4051, '.NS_SVC.4051' service.
[64] End of TI_NN_StartService. Service 4051 started. ---
[64] MS: MessageServiceRegister called.
[64] MS: MessageServiceRegister called.
[64] MS: MessageServiceRegister called.
[64] MS: MessageServiceRegister called.
[64] MS: MessageServiceRegister called.
[64] MS: MessageServiceRegister called.
[64] MS: MessageServiceRegister called.
[64] MS: MessageServiceRegister called.
[64] Start install OS service
[64] Entered TI_NN_StartService. Service Id: 4080 +++
[64] Start service: port 4080, '.NS_SVC.4080' service.
[64] End of TI_NN_StartService. Service 4080 started. ---
[64] Start node info service.
[64] Entered TI_NN_StartService. Service Id: 4020 +++
[64] Start service: port 4020, '.NS_SVC.4020' service.
[64] End of TI_NN_StartService. Service 4020 started. ---
[64] Entered TI_NN_StartService. Service Id: 4042 +++
[64] Start service: port 4042, '.NS_SVC.4042' service.
[64] End of TI_NN_StartService. Service 4042 started. ---
[64] Start screen service
[64] Entered TI_NN_StartService. Service Id: 4024 +++
[64] Start service: port 4024, '.NS_SVC.4024' service.
[64] End of TI_NN_StartService. Service 4024 started. ---
[64] Entered TI_NN_StartService. Service Id: 4052 +++
[64] Start service: port 4052, '.NS_SVC.4052' service.
[64] End of TI_NN_StartService. Service 4052 started. ---
[64] TI_NN_RegNotifyCB Called. +++
[64] CM: RegisterNotifyCallback called.
[64] End of TI_NN_RegNotifyCB. Notify Callback registered. ---
[64] New API: Load connector after all services started.
[64] Initializing 2 Connector(s).
NavNet Ready.


Chaque message "[64]" appelant une ouverture, écriture et fermeture du fichier "navnet.log.csv", cet OS fonctionne sensiblement plus lentement que les autres, ce qui est particulièrement visible au moment où le Boot2 démarre l'OS après l'avoir chargé, avec toute la série des messages qui s'enregistrent.



En fait, il ne s'agit pas de notre premier OS Nspire de debug. En visite chez TI-Dallas lors de l'été 2011, Adriweb avait à l'époque découvert et photographié un OS Nspire de debug 1.8, version qui n'est d'ailleurs jamais sortie puisque l'on est passé directement de 1.7 à 2.0:


Mais à l'époque, nous avions beaucoup moins de recul pour comprendre ce dont il s'agissait.




Lien:
OS TI-Nspire CAS prototype 1.4.8092 de debug

Dommage que le navnet.log.csv ne soit pas plus détaillé (dumps des paquets, par exemple).
Le log mentionne un service 0x4052 dont on ne sait, à ma connaissance, rien.

A noter qu'on sait depuis longtemps que des chaînes de caractères comme "Entered TI_NN_StartService" peuvent facilement être trouvées dans les phoenix.raw des OS de production, même 3.1.0.392 et 3.2.0.1219.
Ou bien elles ne sont pas du tout utilisées - ce qui voudrait dire que TI gaspille de la mémoire Flash pour le stockage, et RAM pour l'exécution, de façon parfaitement artificielle et stupide - ou bien il se pourrait bien qu'il y ait une façon d'activer ce debug, même dans les OS de production. Mais il n'y a pas de références à "navnet.log" ou "csv" correctes, donc malheureusement, je pencherais plutôt pour la première solution... d'autant plus que ce n'est pas la première fois que TI gaspille de la place dans ses OS, ça arrivait également sur TI-68k.