Au (re)démarrage, ta
TI-Nspire CX lance soit une image de démarrage
Boot2 (ou plus récemment Boot1.5 mais c'est le même format), soit une image de diagnostic
Diags.
Ces images sont bien évidemment signées électroniquement de façon totalement infalsifiable en 2048-bits, et il n'est donc en théorie pas possible de les modifier.
En pratique, l'outil
nBoot sorti en
mai dernier permet d'injecter du code autorisant l'exécution d'images non signés.
Malgré une entête ressemblant à celle des images
Boot2/Diags, ces images ont un format différent, plusieurs champs ayant soit des significations différentes, soit étant totalement ignorés. Nous parlerons du format
nBoot.
nBoot venait également avec une image permettant de lancer
Linux, mais là encore avec un format d'image différent, une extension du précédent que l'on appellera
nBootLinux.
Bref, 3 formats d'images voisins mais différents,
Boot2/Diags,
nBoot et
nBootLinux, nécessitant donc plein de cas particuliers dans tout outil gérant les partitions de démarrage
(nsNandMgr, BtMg, nsPartManagic...).
Je n'aurais certainement pas fait comme ça, mais maintenant il n'y a pas d'autre choix que de faire avec.
Les images
nBoot avaient le défaut de devoir prendre la place de l'image
Diags (début de la partition éponyme), rendant par la suite impossible plusieurs manipulations de maintenance, sans compter qu'il n'était alors pas possible d'en faire cohabiter plusieurs.
Heureusement,
par la suite est sorti
ControlX, une image
nBoot qui avait la particularité d'être capable de lancer d'autres images trouvées dans les partitions
Boot2,
Diags ou
ExtnD - bref, un gestionnaire de démarrage.
Dans sa version initiale,
ControlX reconnaissait tous les formats d'images, mais était uniquement capable de lancer :
- les images Boot2/Diags
- les images nBootLinux
Le format
nBoot n'était pas géré à cause d'une difficulté technique, les images
nBoot devant être chargées et exécutées à l'adresse 0x10000034, adresse à laquelle résidait déjà
ControlX puisque issu lui-même d'une image
nBoot.
Or, il n'est pas possible pour un code en cours d'exécution de s'écraser lui-même...
Pour développer de petits programmes lançables à chaque (re)démarrage de ta
TI-Nspire CX, tu avais donc le choix entre :
- le format nBoot, facile à générer en se basant sur le Makefile de ControlX, mais qui n'était exécutable que par nBoot, et de plus imcompatible avec la présence d'un Diags, de ControlX ou de tout autre image nBoot sur la machine
- le format Boot2/Diags, qui a l'avantage de pouvoir gérer la compression de code, mais plus difficile à générer par absence de Makefile public à ce jour, et qui n'était exécutable que par ControlX
Aujourd'hui sort
ControlX 4.3.1 qui subit une évolution majeure en étant désormais capable d'exécuter les images au format
nBoot, c'est-à-dire d'écraser son propre code après quelques acrobaties en mémoire.
Même si c'est inutile, cela veut dire entre autres que ControlX est désormais capable de relancer sa propre image depuis son propre menu. 
Le développement d'images exécutables à chaque (re)démarrage de ta
TI-Nspire CX devient donc désormais beaucoup plus accessible !
On peut imaginer plein de choses qui une fois installées resteront par la suite toujours disponibles peu importe l'état de la machine
(avec ou sans Ndless, avec ou sans OS...), comme des outils de maintenance et bien d'autres choses encore...
D'ailleurs, nous te sortons une image
nBoot de démo avec un
Makefile fonctionnel dont tu pourras repartir pour créer tout ce que tu voudras si ton
Ndless SDK est à jour,
Splash 1.0, qui comme son nom l'indique pourra t'afficher sur demande une image plein écran à chaque (re)démarrage de ta machine.
Pour ceux qui souhaitent tester, il est conseillé de programmer l'image Splash 1.0 avec BtMg, soit dans la partition ExtnD, soit dans la partition Diags mais alors après l'image de ControlX.Téléchargements :Ressources : Tutoriel d'installation + mise à jour ControlX
by 
Et puis tous ces brins d'herbe absolument identiques les uns à côté des autres, cela fait très artificiel...
