[critor]

Dans une news précédente suite à la sortie de l'OS Nspire 3.0.1, nous découvrions un étrange fichier "theme.csv" stocké à la racine des documents Nspire et invisible sur la calculatrice.

Le contenu du fichier une fois récupéré nous suggérait la possibilité de personnaliser l'affichage Nspire, ce qui serait d'autant plus utile sur les modèles couleurs:

eWindowTitleBarBackground,0xFFFFFF,0xFF0000
eWindowTitleBarForeground,0xFFFFFF,0xFF0000
eWindowTitleBarTextBackground,0xFFFFFF,0xFFFF00
eWindowTitleBarTextForeground,0x000000,0x00FF00

Hélas, différentes tentatives de modification du contenu de ce fichier n'avaient malheureusement rien donné.

Mais peut-être était-ce une fonctionnalité expérimentée dans les OS Nspire de développement, et pour le moment non reprise dans les OS de production?...



Et bien une photo exclusive vient ce soir confirmer cette dernière hypothèse, et révéler l'existence, au moins dans les OS de développement, d'un éditeur de thème pour TI-Nspire!

Sera-t-il cette fois-ci inclus dans l'OS 3.2 qui devrait sortir en mai, ou remis à une version ultérieure? En tous cas les documents officiels ne le mentionnent pas pour le moment - mais quoiqu'il arrive, nous avons désormais la preuve de son existence!

[Lionel Debroux]

Peut-être vous souvenez-vous d'imgdump, l'outil dont toutes les versions permettent de décompresser le boot2 des Nspire, et dont certaines versions permettent de déchiffrer l'OS des Clickpad & Touchpad.

Une version améliorée, destinée aux développeurs (fournie sans binaires, pour des raisons évidentes), avait été publiée il y a quelques semaines sur TI-Planet: imgdump.

Aujourd'hui est publié imgmanip, version un peu plus récente d'imgdump, disposant en plus de la capacité de compresser en utilisant le même algorithme que celui que TI utilise pour les boot2
imgmanip reste, comme les versions récentes d'imgdump, destiné aux développeurs: ceux qui savent compiler, lire et modifier du code C(++).

Ceci s'inscrit dans la lignée de ce que critor a mentionné tout à l'heure Boot2 et Diags interchangeables: un pas vers le dual Boot?), et pourrait éviter la réinvention de la roue à ceux qui voudraient faire des expériences avec FlashBoot2, FlashBoot2CX, FlashDiags et FlashDiagsCX.

Naturellement, les expérimentateurs ne doivent pas oublier que les boot2 et diags sont signés avec des clés RSA privées que seul TI possède, validés par les clés RSA publiques présentes dans le boot1

Show/Hide spoilerAfficher/Masquer le spoiler

Pour rappel, il est calculatoirement infaisable (pour nous) de factoriser des clés publiques de 768 bits et plus. Même la plus grande grille de calcul dédiée à la factorisation d'entiers, NFS@Home, ne peut pas factoriser des clés RSA 768 bits, et les clés 1024 bits sont encore au moins trois ordres de grandeur (x1000+) plus difficiles à factoriser
En 2009, à la fin de leur factorisation de RSA-768, même les chercheurs à la pointe de la factorisation d'entiers n'envisageaient pas (sauf improbable percée algorithmique) la factorisation de RSA-1024 avant 2015 environ, et ils sont les seuls à disposer des ressources (milliers d'années CPU) et des implémentations (à toutes les phases) capables de mener à bien ce genre de factorisations.

[critor]

En février 2011, nous découvrions le nouveau module sans-fil TI-Nspire CX Navigator, ce qui nous avait alors permis de prédire la sortie de la nouvelle calculatrice TI-Nspire CX:

Ce module a été véritablement miniaturisé par rapport à sa version précédente!
(http://tiplanet.org/images/nswifi9.jpg)


Qu'y a-t-il donc vraiment dedans? Découvre-le ce soir sur TI-Planet sur son prototype EVT2, avec de premières vraies photos en gros plan du dehors et du dedans!

[critor]

Normalement au démarrage, votre TI-Nspire effectue dans l'ordre les opérations suivantes:

• Lancement du Boot1
• Vérification et décompression du Boot2 par le Boot1
• Lancement du Boot2
• Vérification et décompression de l'OS par le Boot2
• Lancement de l'OS

Si vous maintenez enfoncées les touches au démarrage, la procédure d'initialisation est alors altérée:

• Lancement du Boot1
• Vérification du Diags par le Boot1
• Lancement du Diags

Vous accédez alors au logiciel de diagnostics:

Mais depuis deux news précédentes, nous disposons de programmes Ndless pour reprogrammer le Boot2 et reprogrammer le Diags.



Et bien que se passe-t-il si l'on reprogramme le Boot2 avec un logiciel de Diagnostics?

TI-Planet a tenté cette opération contre-nature, et miracle! A l'allumage, la TI-Nspire lance le logiciel de diagnostics qu'elle prend pour un Boot2 sans se poser aucune question!

Le Boot1 ne fait donc pas de différence entre les images de logiciels de diagnostics et les images de Boot2!



Sans intérêt? Imaginez l'opération inverse... Imaginez que l'on reprogramme le logiciel de diagnostics avec une 2ème version du Boot2! Et voilà, c'est le premier pas vers un Dual-Boot sur les TI-Nspire! Il suffirait de maintenir au démarrage pour utiliser le Boot2 alternatif!



Toutefois en pratique il y a un petit problème: le logiciel de diagnostics ne peut pas excéder 640Ko, et tous les Boot2 sortis par TI sont plus gros à l'exception de ceux équipant les TI-Nspire Lab Cradle, mais qui seraient sans intérêt sur de véritables calculatrices Nspire.

[Lionel Debroux]

tangrs, déjà auteur de nombreux travaux et programmes fort intéressants pour la Nspire (entre autres: compilation de C++ avec Ndless, effet rétro à l'extinction de la machine, Nspire Movie Player, prototype de multi-threading, horloge), continue à travailler sur le chargement de programmes

Les lecteurs se demanderont peut-être pourquoi il est utile d'avoir ce genre de chargeurs. La réponse est simple: pour pouvoir bénéficier d'une facilité de programmation plus proche de ce qui se fait sur la plupart des environnements de programmation, dont les TI-68k d'ailleurs - par exemple, les variables globales relogées
L'absence de relocation automatique nécessite de faire ces relocations à la main, ce qui complique singulièrement la réalisation des gros programmes. Ndless fournit nl_relocdata, mais c'est fastidieux à utiliser, et peut être difficile.


Bref, un petit peu d'historique des loaders de tangrs:
* il y a des mois, tangrs avait fait ndless-elfloader, prototype de chargeur ELF, c'est à dire le format extensible et portable de fichiers objet et binaires, utilisé sur Linux depuis des années. C'était assez compliqué et lourd, et certains fichiers à charger étaient très gros alors qu'ils ne contenaient que très peu de code. Voir http://www.omnimaga.org/index.php?topic=11904.0 pour plus de détails.
* hier, il a fait un chargeur ajouté au programme par un outil côté ordinateur, qui a pour but de reloger le programme avant de déclencher son exécution, ndless-standalone-relocator: http://www.omnimaga.org/index.php?topic=13117.0 . Et au cours de cette dernière discussion, "bFLT" a de nouveau été mentionné.
bFLT est un format beaucoup plus simple qu'ELF, il peut facilement être obtenu à partir de fichiers ELF et facilement chargé, mais il est suffisant pour résoudre les plus gros problèmes de relocation que nous rencontrons actuellement. De plus, il est utilisable pour gérer des librairies dynamiques et des binaires compressés (le loader bLFT du kernel Linux sait faire).

* tangrs s'est donc vraiment intéressé à bFLT... et quelques heures plus tard, le nouveau prototype ndless-bflt-loader est né, avec sa documentation développeur pour ajouter le convertisseur ELF -> bFLT à l'environnement de développement et changer les Makefiles
Il l'a annoncé dans le même topic que ndless-standalone-relocator: http://www.omnimaga.org/index.php?topic ... #msg240684 .
Puis un topic a été créé: Ndless bFLT loader .


Gageons que ce loader va continuer à se développer rapidement, puisque tangrs développe vite, et qu'il sera vite adopté (par nSDL, par exemple)