Forum TI-Planet.org

Dans un article précédent, Lionel vous parlait d'un nouveau firmware tiers pour calculatrice HP-Prime, développé par Jean-Baptiste Boric.

Ce firmware ne fait pas grand chose à ce jour, et n'allume même pas l'écran pour le moment. Mais il n'empêche qu'il démontre son contrôle désormais total sur le matériel en allumant les diodes examens pour indiquer le mode dans lequel il a été démarré, composants censés être les plus critiques de la machine et donc les plus sécurisés :

• mode 'payload' : par défaut - signal périodique tricolore
• mode "GDB stub" : maintenir enfoncée la touche

  ON

  - diode bleue allumée

Pour la première fois ce soir, vous pouvez donc contempler ce nouveau firmware en pleine action :


Il resterait donc maintenant à rendre ce firmware utile. Si développer un firmware complet à partir de rien peut paraître trop coûteux en terme d'investissement, surtout dans le contexte très précis des Mathématiques et des Sciences, un portage de Linux serait par contre lui parfaitement envisageable.

Heureusement à ce jour, il est impossible à un surveillant d'examen formé et avisé de confondre ce signal lumineux avec celui du mode examen.
En effet, les signaux officiels du mode examen HP-Prime sont :

• mode examen de base (pour la France) : signal vert périodique
• mode examen personnalisé (autres pays) : signal tricolore aléatoire

Les signaux bleu continu et tricolore périodique générés ici par le firmware tiers sont donc complètement différents.



Mais ce n'est qu'un détail qui serait facilement modifiable, et cela ne fait que démontrer ce que nous avions déjà dénoncé : la nouvelle réglementation imposant le mode examen à compter de 2018 n'apporte strictement rien, aucune sécurité ni garantie dans le contexte des machines personnelles que les candidats utilisent en France - il faudra circuler et regarder si il y a des choses suspectes sur les écrans des candidats plutôt que de se fier aux diodes, ce qui impliquera de connaître parfaitement chacun des modèles avec leurs capacités intégrées et préchargées.

Dans un tel contexte, il eut simplement suffi d'écrire dans le texte officiel que les candidats devaient effacer leur mémoire en début d'épreuve et point - il n'était nullement nécessaire de contraindre toutes les familles de Seconde ainsi que certains étudiants ou futurs étudiants à renouveler à leurs frais l'ensemble du parc national des calculatrices graphiques pour rien au final.

Le pire étant que l'un de nos buts dans cette intervention qui ne se voulait que bienveillante, était d'éviter à l'Institution de se ridiculiser... si si...



Même si l'équipe TI-Planet ne travaille absolument pas sur des moyens de falsifier ou contourner le mode examen, nous avons testé en détails l'ensemble des modèles conformes pour 2018 et avons un avis sur la sécurité de chacun de leurs modes examens.

Nous ne sommes certes absolument pas étonnés que du code tiers ait été capable de prendre le contrôle des diodes examen sur la HP-Prime, ce modèle pouvant être qualifié selon nous de totalement dépourvu de sécurités par rapport à d'autres.

Mais nous sommes par contre assez surpris que ce soient les diodes examen de la HP-Prime qui soient tombées en premier face à du code tiers, et non celles de certains des autres modèles conformes actuellement commercialisés... Non pas tellement parce qu'ils sont plus répandus, mais surtout parce qu'ils sont encore moins bien sécurisés...

critor wrote:Il resterait donc maintenant à rendre ce firmware utile. Si développer un firmware complet à partir de rien peut paraître trop coûteux en terme d'investissement, surtout dans le contexte très précis des Mathématiques et des Sciences, un portage de Linux serait par contre lui parfaitement envisageable.

Personnellement j'ai plutôt dans l'idée de porter NetBSD. Parce que "Of course it runs NetBSD"

critor wrote:Heureusement à ce jour, il est impossible à un surveillant d'examen formé et avisé de confondre ce signal lumineux avec celui du mode examen.
En effet, les signaux officiels du mode examen HP Prime sont :

• mode examen de base (pour la France) : signal vert périodique
• mode examen personnalisé (autres pays) : signal tricolore aléatoire

Les signaux bleu continu et tricolore périodique générés ici par le firmware tiers sont donc complètement différents.

Au delà de ça, je rajouterai que faire démarrer le stub GDB ou dummy.elf rend la HP Prime aussi utile qu'une règle non graduée en examen, vu que le firmware officiel ne tourne pas.

Se passer de ce qui fait cette calculette une calculette devrait en refroidir plus d'un d'utiliser Rip'Em en examen...

Personnellement j'ai plutôt dans l'idée de porter NetBSD. Parce que "Of course it runs NetBSD"

A la rigueur NetBSD, le n°2 en termes de portabilité, à des fins d'apprentissage... mais pour les choses sérieuses, il faut Linux, comme toujours, because "Of course it runs Linux"

Linux, de loin le n°1 en portabilité pour les OS d'usage général, gère plus d'ISAs et beaucoup plus de plate-formes complètes que même NetBSD. Linux gère déjà bien le S3C2416, voir les pages que j'avais linkées dans des sous-pages de https://tiplanet.org/hpwiki .

Lionel Debroux wrote:mais pour les choses sérieuses, il faut Linux, comme toujours

Je ne relèverai pas le évident, je m'en tiendrai donc aux arguments techniques

Entre mes contributions à MINIX 3 et ma résurrection avortée du port de la PlayStation 2 de NetBSD, je suis de loin beaucoup plus familier avec les entrailles de NetBSD que celles de Linux.

NetBSD gère aussi la famille S3C24XX, d'ailleurs c'est dans le code source de NetBSD que j'ai remarqué des ressemblances entre l'HP Prime et les cartes d'évaluations de cette famille de SoC (par exemple pour le mini2440 : mêmes GPIO pour les LEDs, même GPIO pour le rétro-éclairage. Coïncidence ? Peut-être, peut-être pas...).

Porter le noyau Linux c'est bien, porter le noyau Linux avec un user-land qui permette d'en faire quelque chose en pratique c'est mieux. Avec NetBSD, le noyau est fourni avec un user-land complet.

Porter Doom? Y'a qu'à demander à pkgsrc.

Enfin, build.sh permet de construire une toolchain + un noyau + un user-land complet en une ligne de commande. On fait difficilement plus clés en main que ça.

Bref, ne serait-ce que pour la première raison ce sera NetBSD pour moi : après tout, je suis déjà familier avec son code source.

Je ne relèverai pas le évident

Ha ha, j'ai dû manquer un peu de finesse
Mais tu as tout à fait raison de ne pas répondre aux trolls trop évidents.

Entre mes contributions à MINIX 3 et ma résurrection avortée du port de la PlayStation 2 de NetBSD, je suis de loin beaucoup plus familier avec les entrailles de NetBSD que celles de Linux.

Vu comme ça, c'est clair que tu porteras plus facilement NetBSD, et à ta place, je ferais probablement la même chose.
Mais du même coup, tu appendrais davantage en portant Linux

(par exemple pour le mini2440 : mêmes GPIO pour les LEDs, même GPIO pour le rétro-éclairage. Coïncidence ? Peut-être, peut-être pas...).

C'est fréquent, en effet, pour faciliter les tests par ceux qui font la plate-forme. Et ça facilite l'émulation, pour les autres.

Porter le noyau Linux c'est bien, porter le noyau Linux avec un user-land qui permette d'en faire quelque chose en pratique c'est mieux. Avec NetBSD, le noyau est fourni avec un user-land complet.

Porter Doom? Y'a qu'à demander à pkgsrc.

Enfin, build.sh permet de construire une toolchain + un noyau + un user-land complet en une ligne de commande. On fait difficilement plus clés en main que ça.

Difficilement, en effet
Même si comme tu le sais, sous GNU/Linux, on a en général accès à des user-spaces précompilés très complets en quelques commandes, par exemple debootstrap sur les Debian (pour une Prime, ce serait l'architecture armel pour avoir des binaires armv4t), et qu'il y a des choses comme buildroot pour obtenir toolchain + kernel + user-land, ça reste plusieurs commandes.

Pour information.


Nous avions trouvé un gros problème sur les HP-Prime munies du firmware officiel, avec les diodes examen arrivant à épuiser la batterie en moins d'une journée écran éteint, là où les autres modèles tiennent des semaines ou même des mois :
viewtopic.php?t=17142&p=188203

Ce qui pourrait être assez problématique lors d'une semaine d'examens...


J'ai fait le test avec le firmware tiers précédent, et la machine vient de s'éteindre définitivement.
Elle a donc tenu autour de 18heures depuis hier soir - on reste donc dans la même fourchette malgré le changement de firmware.

Ce qui pourrait vraiment signifier que le problème ne vient pas d'un bug du firmware HP mais bel et bien du matériel... je n'arrive pas à comprendre comment trois pauvres diodes peuvent consommer autant.

Dans un tel contexte, on peut se demander si un futur firmware HP pourra véritablement être capable de corriger le problème en atteignant une autonomie comparable à celle des modèles concurrents, ou si, par économie de quelques bouts de chandelles, il arrivera juste à peine à atteindre une autonomie acceptable en semaine d'examens.

Si le firmware de Jean-Baptiste n'utilise pas de mode low power du processeur (je n'ai pas vérifié et je ne peux pas le faire maintenant), et qu'on obtient une autonomie très similaire à celle du firmware officiel, on peut penser que le firmware officiel n'utilise pas de mode (very) low power quand il faut faire clignoter les LEDs. Ce dont on se doutait déjà: l'autonomie de la Prime est certes bonne en conditions normales d'utilisation, et en veille, mais à raison de plusieurs heures par jour, la Prime ne dure quand même pas des semaines.
Pour l'instant, on ne peut pas savoir si c'est une limitation du matériel ou du firmware, qui utiliserait mal / pas les modes low power - à supposer qu'il existe des modes permettant de faire clignoter les LEDs tout en maintenant une consommation minimale d'énergie, bien sûr. L'absence de tels modes serait une limitation du matériel.

On va donc bien voir ce que Jean-Baptiste en dit.

Mais personnellement, j'ai du mal à accepter que 3 pauvres diodes puissent consommer apparemment davantage qu'un écran rétroéclairé...

A mon sens, le problème n'est pas la consommation directe des LEDs.

Dans tous les cas, merci pour tes précieuses précisions.


Tu penses à un circuit sur le chemin conduisant aux LEDs ?

Ou au fait qu'en mode examen personnalisé le processeur doit rester dispo pour générer le motif lumineux aléatoire ?
Si oui, ce ne serait pas nécessaire dans le mode examen de base (vert périodique).
Mais même à ça, il me semble qu'avec l'écran allumé le processeur devrait se taper des calculs bien plus épuisants que la gestion d'un simple motif à 3 bits.