Forum TI-Planet.org

Pour l'écriture de la flash, je ne compte pas le faire depuis epsilon. Il y a trop de travail pour intégrer la gestion de l'USB (vu que la licence est plutôt restrictive). A la limite, ça peut se faire facilement avec l'UART interne mais ça oblige à plus de modifications sur la calculatrice. Du coup, je suis en train de tester un firmware dédié pour ça, mais j'aimerais l'exécuter directement depuis la RAM pour ne pas avoir à le flasher à chaque fois, mais sans trop de succès pour le moment.

Effectivement, le ST-Link est une bonne idée, mais c'est encore mieux avec ce firmware dessus : https://github.com/blacksphere/blackmagic C'est grosso modo ce que j'utilise actuellement.

En effet, intégrer la gestion de l'USB est techniquement d'autant plus de travail qu'ils n'utilisent pas de RTOS... et légalement, leur licence est une fois de plus un frein au développement de leur machine...
Puisque tu as un debugger hardware, c'est une bonne idée d'exécuter le firmware de flashage depuis la RAM.

Jolie mention par NumWorks

Merci pour les puces de flash, elles sont bien arrivées !

J'ai un peu avancé ce soir sur la programmation de la flash dans la calculatrice. J'arrive enfin à ce que mon code s'exécute dans la RAM, et à faire fonctionner l'interface USB en émulation de port série. Je pense du coup implémenter le protocole serprog de flashrom (https://www.flashrom.org/Serprog). Cela permettrait de déporter les spécificités de chaque flash hors du firmware. Par contre, j'ai bien l'impression d'être un peu coincé par le contrôleur QSPI. Principalement, il ne me semble pas qu'il permettre d'écrire puis de lire un nombre arbitraire d'octets depuis le bus SPI, ce qui est nécessaire pour serprog...

Merci pour les puces de flash, elles sont bien arrivées !

Super

et à faire fonctionner l'interface USB en émulation de port série

Famille CDC, ou bien l'un des devices en classe vendor-specific: PL230x, CP210x, FTDI-232*, etc. ?

Cela permettrait de déporter les spécificités de chaque flash hors du firmware.

Pour démarrer, je vois un peu l'intérêt, mais d'un autre côté, vu que pour pouvoir gérer la Flash externe depuis le firmware standard, il faudra, un jour où la licence sera moins restrictive, implémenter dans celui-ci une gestion des queries CFI, get status, write word et block erase (qui seraient référencées par exemple en tant qu'entrées pointeur de fonction / pointeur de fonction membre dans un petit tableau de struct ou class), il ne me semblait pas majeur. Mais ce n'est pas moi qui fais le boulot

Principalement, il ne me semble pas qu'il permettre d'écrire puis de lire un nombre arbitraire d'octets depuis le bus SPI, ce qui est nécessaire pour serprog...

Oh. Si la valeur maximale atteignable de Q_WRNMAXLEN est inférieure à celle d'une page de Flash, c'est plus pénible à utiliser, en effet.

J'ai reçu les puces. Plus qu'à acquérir la relève du vénérable JBC 40S familial pour pouvoir s'en servir (et sévir).

Pour flasher les puces, vu que je suis feignant et que je n'ai pas envie de réinventer la roue je vais probablement récupérer un bootloader DFU open-source existant pour STM32F.

A plus long terme, j'ai réfléchi aux protocoles de communication USB, le MTP me semble tout indiqué pour le transfert de données. Il expose un système de fichiers purement logique à l'hôte, ne nécessite pas de drivers particuliers et a déjà fait ses preuves avec les smartphones.

Pour flasher les puces, vu que je suis feignant et que je n'ai pas envie de réinventer la roue je vais probablement récupérer un bootloader DFU open-source existant pour STM32F.

Je n'en ai trouvé aucun dispo capable de flasher sur le bus QSPI. Bref, j'espère ne pas avoir réinventé la roue, mais voici le mien : https://github.com/zardam/qspi_loader

Testé avec la Windbond (merci encore !), un peu moins de 3 minutes pour programmer les 16 Mo de la flash.

Au passage, j'ai corrigé et adapté ma branche d'epsilon. Du coup la flash externe fonctionne parfaitement en mode "memory mapped" ! (je suis resté sur une fréquence assez basse car mon setup n'est pas top, ça décroche au dessus de 24 MHz, mais rien n’empêche d'aller plus haut normalement).

Attention par contre, ça risque de consommer de la batterie, rien n'est fait pour limiter la consommation de la flash pour le moment.

Si quelqu’un se sent de compiler une version de GIAC pour le CPU, je veux bien tester l'intégration. J'ai commencé à regarder mais il se fait vraiment tard...

Le manuel en deux mots : une fois le flasher compilé il faut l'uploder avec

Code: Tout sélectionner

dfu-util -i 0 -a 0 -s 0x20008000:force:leave -D qspi_loader.bin

et ensuite charger le contenu de la flash avec (à adapter)

Code: Tout sélectionner

flashrom -p serprog:dev=/dev/ttyACM0 -V -w ~/flash.bin

Il suffit ensuite de faire un reset de la calculatrice.

Super boulot

Pour les premières étapes d'exécution de code depuis la Flash externe, j'avais suggéré des choses plus simples que giac, parce que réaliser l'intégration dans les deux sens avec l'OS standard nécessite un certain boulot. Il faut notamment que:

• giac sache où sont les points d'entrée de l'allocateur mémoire: malloc(), free(), operator new / new[] / delete / delete[] (à moins d'utiliser ces derniers de façon inline, cf. par exemple https://github.com/debrouxl/epsilon/com ... d392fd6bc2 , qui augmente l'efficacité du code - ces changements sont suffisamment simples pour être refaits par quelqu'un d'autre a signé le CLA);
• le linker sache où il doit mettre les .data et .bss de giac en RAM et les .text et .rodata en Flash externe, alors que sur l'OS standard, .text et .rodata sont en Flash interne.
  Le script linker de l'OS standard est ion/src/device/boot/flash.ld. Je ne sais pas si, sans modifier lourdement le code de giac pour définir les noms des sections .text et .rodata (je n'ai pas vu rapidement d'option pour ce faire dans `man gcc`), on peut réussir à faire un seul script linker pour l'OS standard + giac.

@JB: ouais, MTP est une autre possibilité. A voir comment mapper sans trop de contorsions, peut-être sur des chemins virtuels spéciaux, les opérations non évidemment fichier comme "send one keypress / send multiple keypresses" et le cas échéant des opérations plus avancées de remote control (exécution de programmes d'un certain type), "get screenshot", "get calculator information", ou peut-être "set exam mode settings". Les cinq opérations existent sur les calculatrices TI, pas toutes simultanément, et au moins trois existent sur la HP Prime.

Merci à tous deux d'avoir pris le temps de confirmer la bonne réception de l'envoi.

giac sache où sont les points d'entrée de l'allocateur mémoire: malloc(), free(), operator new / new[] / delete / delete[] (à moins d'utiliser ces derniers de façon inline, cf. par exemple https://github.com/debrouxl/epsilon/com ... d392fd6bc2 , qui augmente l'efficacité du code - ces changements sont suffisamment simples pour être refaits par quelqu'un d'autre a signé le CLA);
le linker sache où il doit mettre les .data et .bss de giac en RAM et les .text et .rodata en Flash externe, alors que sur l'OS standard, .text et .rodata sont en Flash interne.
Le script linker de l'OS standard est ion/src/device/boot/flash.ld. Je ne sais pas si, sans modifier lourdement le code de giac pour définir les noms des sections .text et .rodata (je n'ai pas vu rapidement d'option pour ce faire dans `man gcc`), on peut réussir à faire un seul script linker pour l'OS standard + giac.

Pour un firmware "monolithique", le linker devrait se débrouiller tout seul (ou presque) il me semble ?

Au pire, mettre tout dans la flash externe, sauf l'initialisation bas niveau ? C'est un peu dommage, mais ça suffirait pour un proof of concept, et sans trop de modifications.

C'est certes "quick'n dirty", mais de toute façon je n'ai pas vraiment le temps de faire mieux (le but étant surtout d'apprendre au passage).