NumBoots - Bootloader pour NumWorks N0110

[jean-baptiste boric]

J'ai expérimenté un peu ce week-end afin de résoudre le problème des apps tierce-parties perpétuellement cassées sur les calculatrices NumWorks.

Pour faire court, c'est un bootloader pour NumWorks N0110 qui permet de démarrer des exécutables. Lors d'un reset, un menu présente les fichiers dans la Flash externe pour sélectionner un programme à démarrer. Ce n'est pas un shell à proprement parler étant donné que les programmes sont standalone, mais cela offre une indépendance par rapport aux fluctuations du firmware officiel.

Les avantages de cette approche sont l'indépendance vis-à-vis du firmware officiel et de sa licence, les programmes ont un accès complet aux 256 KiB de RAM sans avoir à partager avec quiconque et la présence d'un simili-système de fichiers permet de stocker des choses (par exemple, avoir plusieurs fichiers ROMs pour un émulateur NES quand/si un sortira).

L'inconvénient majeur est qu'il faut faire un reset pour changer de programme. Le bouton est plus facile d'accès que sur la N0100, mais cela implique la perte des données d'epsilon (scripts Python, fonctions/variables...). Cela se prête donc plutôt aux programmes indépendants du firmware officiel, comme des émulateurs ou des firmwares alternatifs. L'isolement des applications va aussi coûter plus de Flash par rapport à une approche de type shell où les programmes peuvent se reposer sur les fonctionnalités du firmware.

Ce qui manque maintenant c'est une HAL pour faire des programmes. J'ai picoré celle de NumWorks pour faire le sample, mais il faudra en écrire une from scratch si on souhaite s'affranchir de la licence d'epsilon. J'ai réussi à trouver une solution qui ne nécessite pas de ré-architecturer epsilon, la maintenance ne devrait pas être trop chronophage.

Techniquement rien n'empêcherait de faire la même chose sur des N0100, mais la quantité limitée de Flash et la taille du firmware officiel fait que ce serait d'une utilité plus que discutable.

C'est encore très brut de décoffrage, mais c'est utilisable.

Code: Select all

make EPSILON_DEVICE_BENCH=0 EPSILON_USB_DFU_XIP=0 EPSILON_ONBOARDING_APP=1 EPSILON_BOOT_PROMPT=update build/device/n0110/epsilon_two_binaries -j
python scripts/device/prg.py build/device/n0110/epsilon.external.bin epsilon.external.bin ../lenna/lenna.prg
sudo dfu-util -D build/device/n0110/epsilon.internal.bin -s 0x08000000
sudo dfu-util -D epsilon.external.bin -s 0x90000000


Sources:

• https://github.com/boricj/epsilon/tree/numboots
• https://github.com/boricj/numboots-lenna

[critor]

Bien, quelle rapidité !

Bon maintenant, histoire que ce soit accessible au plus grand nombre, il faudrait mettre à jour https://ti-planet.github.io/webdfu_numworks/ pour permettre l'écriture de la partie externe du firmware.

[Adriweb]

J'accepte les PR

[zardam]

Très bonne idée, cela ouvre beaucoup de possibilités !

[parisse]

En effet!
Une des possibilites est de compiler epsilon avec pour seul app settings, il devient ainsi un OS (et on peut recuperer sur la RAM commune utilisee par les applis). Il me semble qu'on pourrait alors ajouter une application GPL (sans utiliser de code des applications d'epsilon, mais uniquement des appels au code partage entre les applications, code qui joue le role d'OS) et le diffuser sans avoir de conflit de licence. Maintenant que le prototypage de giac est fonctionnel, je vais sans doute attaquer un shell comme sur la Casio qui est un candidat a fournir un firmware diffusable, avec le multiboot pour pouvoir preserver l'utilisation originelle de la calc. Ca sera sans doute assez long, surtout avec la rentree qui se profile...

[critor]

J'accepte les PR

Quel est le problème ?

Ce n'est pas juste intégrer les paramètres DFU spécifiques à la Flash externe que j'ai déjà vu passer ?

[jean-baptiste boric]

Je continue à travailler sur le sujet. Je m’attelle à créer un SDK digne de ce nom (compilateur+libc+bibliothèques) afin d'avoir quelque chose qui tienne la route.

J'ai décidé d'abandonner pour l'instant l'idée d'exécuter du code in-place dans la Flash. C'est une complication inutile pour le moment et newlib ne semble pas supporter du tout ce mode de fonctionnement. Je me replie sur une exécution en RAM avec un loader d'ELF et un système de fichiers de type TAR pour la flash externe (oui, le format d'archive Unix, c'est pour limiter les modifications du côté d'epsilon au maximum avec quelques tours de passe-passe). Ça me permet également de pouvoir réutiliser ma N0100 qui est déjà mutilée pour le debug hardware dans le cadre du développement avec un écart très faible par rapport à la véritable cible.

Je bute pour le moment sur la libc, newlib nécessitant une liste d'options longue comme le bras pour le convaincre de générer du code pleinement compatible avec la NumWorks...

[parisse]

Mais ca risque de diminuer enormement la taille des executables non? Ou bien le code est copie par segments, mais alors on va buter sur la taille de la RAM de la Numworks. Sur la hp39gii, le code est copie de la flash vers la RAM, avec de gros ralentissements pour du code ou on n'a pas pris de precaution pour assurer la localite. Et la RAM etait de 512K dont la moitie reservee a copier du code de la flash vers la ram...

[zardam]

Je bute pour le moment sur la libc, newlib nécessitant une liste d'options longue comme le bras pour le convaincre de générer du code pleinement compatible avec la NumWorks...

Étrange, je n'ai pas eu particulièrement de problème avec ça (pour du code basé sur libopencm3), mais je rate peut être quelque chose.

[jean-baptiste boric]

Mais ca risque de diminuer enormement la taille des executables non? Ou bien le code est copie par segments, mais alors on va buter sur la taille de la RAM de la Numworks.

Comme je l'ai dit, je renonce à l'usage de la flash pour le moment afin de réduire le nombre de problèmes à résoudre dans un premier temps : le code assembleur de newlib n'est pas compatible avec du position-independent code et j'ai déjà assez fort à faire pour faire fonctionner cette lib au forceps. C'est également pour des raisons pratiques, je peux utiliser ma N0100 customisé pour le SWD pour prototyper sans devoir massacrer ma N0110 sur l'autel de la science.

Je m'attaquerai à l'exécution de code depuis la Flash quand j'aurai un SDK fonctionnel (ou alors je contournerai le problème avec du WebAssembly).

Étrange, je n'ai pas eu particulièrement de problème avec ça (pour du code basé sur libopencm3), mais je rate peut être quelque chose.

Je fais une toolchain bare-metal intégrale (binutils+gcc+newlib) depuis les sources, ça me permet d'avoir quelque chose de propre et de réduire drastiquement les options de compilation/linker à mettre explicitement dans les Makefiles, mais c'est inversement proportionnel à la quantité d'incantations magiques pour construire la-dite toolchain afin que ça marche pour de vrai... Ce n'est pas parce que y'a un ELF produit à la fin que la calculatrice est contente pour autant >_<