Challenge NumWorks++ | Flash chip hardware mod
Posted: 01 Oct 2017, 17:36
Objectif :
Officiellement, ce U7 est prévu pour un AT25SF641, "64-Mbit, 2.7V Minimum SPI Serial Flash Memory with Dual I/O, Quad I/O and QPI Support".
Cependant, il semble possible d'utiliser une Flash NOR similaire (même boîtier SOIC-8, même pin layout, même tension d’alimentation, consommations typiques / pic et timings similaires) de 64 ou 128 Mbits (8 ou 16 MB).
Les mémoires Flash NOR QSPI de 256 Mbits et plus utilisent souvent d’autres boîtiers, comme SOIC-16 ou WSON-8, nécessitant une adaptation matérielle, et sont donc plus difficiles à intégrer par des utilisateurs moins expérimentés/outillés.
Il est nettement préférable de coopérer avec les autres développeurs qui s’intéressent à réaliser la même opération pour accélérer le processus… et également de ne pas interférer, voire de collaborer, avec NumWorks.
Réussir à upgrader matériellement sa calculatrice NumWorks pour la doter d'une mémoire Flash externe à l'emplacement prévu pour sur la carte mère.
Cet emplacement, c'est le "U7" sur les schémas. On peut le voir sur la photo ci-contre, à gauche.
Et même en vidéo, avec un chip de flash :
Cet emplacement, c'est le "U7" sur les schémas. On peut le voir sur la photo ci-contre, à gauche.
Et même en vidéo, avec un chip de flash :
Show/Hide spoilerAfficher/Masquer le spoiler
Officiellement, ce U7 est prévu pour un AT25SF641, "64-Mbit, 2.7V Minimum SPI Serial Flash Memory with Dual I/O, Quad I/O and QPI Support".
Cependant, il semble possible d'utiliser une Flash NOR similaire (même boîtier SOIC-8, même pin layout, même tension d’alimentation, consommations typiques / pic et timings similaires) de 64 ou 128 Mbits (8 ou 16 MB).
Les mémoires Flash NOR QSPI de 256 Mbits et plus utilisent souvent d’autres boîtiers, comme SOIC-16 ou WSON-8, nécessitant une adaptation matérielle, et sont donc plus difficiles à intégrer par des utilisateurs moins expérimentés/outillés.
Il est nettement préférable de coopérer avec les autres développeurs qui s’intéressent à réaliser la même opération pour accélérer le processus… et également de ne pas interférer, voire de collaborer, avec NumWorks.
Goal :
The official purpose of that location on the motherboard is to house a AT25SF641 chip : "64-Mbit, 2.7V Minimum SPI Serial Flash Memory with Dual I/O, Quad I/O and QPI Support".
However, using a similar chip (same SOIC-8 package, same pin layout, same supply voltage, similar typical / peak power consumptions) providing 64 or 128 Mbits (8 or 16 MB) of NOR Flash memory. QSPI NOR Flash memories of capacity larger than or equal to 256 Mbits often use different packages, e.g. SOIC-16 or WSON-8, requiring some kind of hardware adaptation, and therefore are harder for users with lower skills or worse tooling to integrate.
Collaborating with fellow developers who have the same aim is highly desirable to proceed faster… as is lack of interference with, or even collaboration with, NumWorks.
Make a successful hardware upgrade of your NumWorks calculator, adding an external Flash memory chip onto the suitable location of the motherboard.
This location is labeled "U7" on the schematics). You can see it in this photo, on the left side.
And even in this official video, with a Flash chip:
This location is labeled "U7" on the schematics). You can see it in this photo, on the left side.
And even in this official video, with a Flash chip:
Show/Hide spoilerAfficher/Masquer le spoiler
The official purpose of that location on the motherboard is to house a AT25SF641 chip : "64-Mbit, 2.7V Minimum SPI Serial Flash Memory with Dual I/O, Quad I/O and QPI Support".
However, using a similar chip (same SOIC-8 package, same pin layout, same supply voltage, similar typical / peak power consumptions) providing 64 or 128 Mbits (8 or 16 MB) of NOR Flash memory. QSPI NOR Flash memories of capacity larger than or equal to 256 Mbits often use different packages, e.g. SOIC-16 or WSON-8, requiring some kind of hardware adaptation, and therefore are harder for users with lower skills or worse tooling to integrate.
Collaborating with fellow developers who have the same aim is highly desirable to proceed faster… as is lack of interference with, or even collaboration with, NumWorks.
Ce qu'il faut faire :
Partie matérielle :
Souder le chip de Flash, 8 plots au pas de 1.27mm (1/20”, 50 mils). C’est bien sûr plus difficile que de souder du matériel au pas de 2.54mm ou 2mm, mais reste accessible. Comme toujours, il ne faut pas trop chauffer le chip et le PCB.
Note additionnelle: il est possible que l’ajout du chip ait un impact sur l'alimentation globale sur la carte mère. Peut-être faut-il s'attendre à des complications à ce niveau là ?
Partie logicielle :
Souder le chip de Flash, 8 plots au pas de 1.27mm (1/20”, 50 mils). C’est bien sûr plus difficile que de souder du matériel au pas de 2.54mm ou 2mm, mais reste accessible. Comme toujours, il ne faut pas trop chauffer le chip et le PCB.
Note additionnelle: il est possible que l’ajout du chip ait un impact sur l'alimentation globale sur la carte mère. Peut-être faut-il s'attendre à des complications à ce niveau là ?
Partie logicielle :
- Ajouter (éventuellement récupérer et adapter) dans l’OS NumWorks un framework et des drivers pour des chips externes de Flash
Voir la datasheet du chip ciblé. Au minimum, le framework d’accès bas niveau à la Flash externe devrait être prévu pour sélectionner un chip de Flash parmi plusieurs à la compilation, mais ça serait encore mieux si on complétait (les deux ne sont pas mutuellement exclusifs) ceci par une sélection dynamique / validation au runtime, basée sur les données CFI; - Prouver que le chip de Flash est utilisable et utilisé
1ère étape : fournir une démonstration simple, vraisemblablement assez rapide à développer, de votre choix. Une des possibilités est d’effacer une partie de la mémoire externe, puis d’y écrire une application embarquée dans le firmware mais indépendante du reste du firmware, ceci lors du démarrage de l’OS (le premier, ou à chaque fois). Un exemple d’application pourrait être un petit jeu avec sauvegarde des paramètres et/ou highscores.
2ème étape : fournir une démonstration plus complexe: embarquer dans l’OS une application destinée à s’exécuter en mémoire externe qui dépend du code (fonctions de calcul flottant, etc.) de l’OS en mémoire interne. Ceci nécessite du travail sur le système de build et probablement sur certains aspects de l’OS lui-même. Une des applications les plus difficiles à déporter est probablement l'application Python.
What you need to do:
In the hardware area:
Solder the Flash chip, 8 pins with 1.27mm (1/20”, 50 mils) spacing. Of course, it’s harder than soldering hardware with 2.54mm or 2mm spacing, but it remains reasonably easy. As usual, excessive heating of the chip and the PCB is a bad thing to do.
Additional note: the addition of a chip might impact the global power supply chain on the motherboard. Maybe some issues are to be expected in that area ?
In the software area:
Solder the Flash chip, 8 pins with 1.27mm (1/20”, 50 mils) spacing. Of course, it’s harder than soldering hardware with 2.54mm or 2mm spacing, but it remains reasonably easy. As usual, excessive heating of the chip and the PCB is a bad thing to do.
Additional note: the addition of a chip might impact the global power supply chain on the motherboard. Maybe some issues are to be expected in that area ?
In the software area:
- Add (possibly by borrowing and modifying) a framework and drivers for external Flash chips to NumWorks’ OS
See the targeted chip’s datasheet. At a minimum, the framework for low-level access to an external Flash memory should be designed to allow selecting a single Flash chip from a set at compile time, but it would be even better if compile-time selection were complemented (they’re not mutually exclusive) by runtime selection / validation of the chip, based on CFI data; - Prove that the Flash memory chip is usable and being used
1st step : build a simple showcase of your choice, whose development should be relatively quick. One of the options is to erase a portion of the external memory, then write an application embedded into the main firmware but independent from it, when the OS boots (for the first time, or every time). For instance, a small game which saves configuration and/or highscores.
2nd step : build a more complex showcase: embed into the OS an application designed to execute from external memory, depending from code (e.g. floating-point functions) from the OS in internal memory. This needs some work on the build system and probably the OS itself. The Python application is probably the hardest to move.
Challenge additionnel niveau software :
L’étape suivante, encore plus difficile, mais beaucoup plus utile, est de coder une méthode générique de transfert de firmware vers la mémoire Flash externe. C’est utile pour gérer plusieurs applications en mémoire externe (c’est une autre étape, mais pas très différente de la gestion d’une seule application en mémoire externe), et nécessaire si on veut pouvoir utiliser plus de code+données que ce qui peut rentrer en mémoire interne, comme le PoC de portage NumWorks réalisé par Bernard Parisse sur le simulateur NumWorks.
Quelques ressources et informations:
L’étape suivante, encore plus difficile, mais beaucoup plus utile, est de coder une méthode générique de transfert de firmware vers la mémoire Flash externe. C’est utile pour gérer plusieurs applications en mémoire externe (c’est une autre étape, mais pas très différente de la gestion d’une seule application en mémoire externe), et nécessaire si on veut pouvoir utiliser plus de code+données que ce qui peut rentrer en mémoire interne, comme le PoC de portage NumWorks réalisé par Bernard Parisse sur le simulateur NumWorks.
Quelques ressources et informations:
Additional software challenge :
The next step, which is even harder but much more useful, is to provide a generic way to transfer firmware to external Flash memory. This is useful to handle multiple applications in external memory (another step, but not that different from handling a single application in external memory), and a prerequisite for using of an amount of code+data too large to fit into the internal memory, such as the NumWorks Giac port PoC performed by Bernard Parisse on the NumWorks simulator.
Several resources and pieces of information:
The next step, which is even harder but much more useful, is to provide a generic way to transfer firmware to external Flash memory. This is useful to handle multiple applications in external memory (another step, but not that different from handling a single application in external memory), and a prerequisite for using of an amount of code+data too large to fit into the internal memory, such as the NumWorks Giac port PoC performed by Bernard Parisse on the NumWorks simulator.
Several resources and pieces of information:
Show/Hide spoilerAfficher/Masquer le spoiler
- Le boot code du STM32F412VG, qui s’occupe du transfert du firmware à travers USB en utilisant le protocole DFU, ne semble pas gérer le flashage d’une mémoire externe, cf. AN2606 “STM32 microcontroller system memory boot mode”. C’est au demeurant compréhensible, parce qu’il y a une grande variété de chips de mémoire externe, disposant de jeux de commandes variés, et qu’il faudrait donner à l’utilisateur le moyen de modifier ce bootloader pour ajouter le support de ses chips…
- AN4852 “Programming an external Flash memory using the UART bootloader built-in STM32 microcontrollers” : http://www.st.com/content/ccc/resource/ ... 281415.pdf
Logiciel correspondant à cette AN :
http://www.st.com/en/embedded-software/ ... tboot.html. Protocole utilisé: AN3155. - Autres logiciels pour STM32, dont des stacks USB :
http://www.st.com/en/embedded-software/ ... tware.html.
Au pire, il est toujours possible de modifier/faire et utiliser un firmware spécial pour la mémoire interne capable de flasher la mémoire externe, qui s’utiliserait de la façon suivante:
- en utilisant le bootloader ST, transférer par DFU le FW spécial de flashage de la mémoire externe, comme les autres FW pour mémoire interne;
- en utilisant le FW spécial, transférer par un certain protocole, logiquement DFU, les données pour la mémoire externe et les écrire au fur et à mesure;
- en utilisant de nouveau le bootloader ST, transférer par DFU vers la mémoire interne la partie principale du FW NumWorks…
Show/Hide spoilerAfficher/Masquer le spoiler
- The STM32F412VG’s boot code, which handles firmware transfer through USB using the DFU protocol, doesn’t seem to handle flashing an external memory chip, see AN2606 “STM32 microcontroller system memory boot mode”. This is understandable, given that there’s a huge variety of external memory chips with different command sets, and therefore, users would need a way to modify the bootloader in order to add support for the chips they want to target…
- AN4852 “Programming an external Flash memory using the UART bootloader built-in STM32 microcontrollers” : http://www.st.com/content/ccc/resource/ ... 281415.pdf
The software corresponding to this AN is:
http://www.st.com/en/embedded-software/ ... tboot.html. The protocol used is described in AN3155. - Other pieces of software for the STM32 family, among which are USB stacks:
http://www.st.com/en/embedded-software/ ... tware.html.
- using ST’s bootloader to make a DFU transfer of the special FW for reflashing the external memory, just like other firmwares suitable for internal memory;
- using the special firmware to make a (probably DFU) transfer of the data to be written into external memory, and write these data blocks the fly;
- using ST’s bootloader again to make a DFU transfer of the main part of the NumWorks firmware to internal memory…
Participation de TI-Planet/UPECS :
Achat + livraison de 2 chips de Flash (un 8 Mo, un 16 Mo avec les mêmes tension d’alimentation, consommation, timings, pas de bloc de boot) à ceux qui voudraient participer, dans la limite des stocks :
Lots à gagner :
Si vous réussissez, vous vous aurez fait votre propre cadeau: une "NumWorks++"... Mais, on peut aller un peu plus loin :
Achat + livraison de 2 chips de Flash (un 8 Mo, un 16 Mo avec les mêmes tension d’alimentation, consommation, timings, pas de bloc de boot) à ceux qui voudraient participer, dans la limite des stocks :
- L'"officiel" listé sur les schémas de NumWorks (64 Mbits = 8 Mo) : Adesto AT25SF641-SUB-T.
- Un autre, avec 2x plus de capacité (128 Mbits = 16 Mo) : Winbond W25Q128JVSIQ.
Lots à gagner :
Si vous réussissez, vous vous aurez fait votre propre cadeau: une "NumWorks++"... Mais, on peut aller un peu plus loin :
- Bien entendu des news à l'honneur du grand bidouilleur ou de l’équipe de grands bidouilleurs, et des possibilités rendues disponibles
- Compte(s) Premium TI-Planet
- Stickers TI-Planet et/ou autres goodies
Vous-êtes intéressé par le challenge et souhaitez participer ? Répondez au topic et/ou envoyez un court e-mail de présentation à info@tiplanet.org
What TI-Planet/UPECS takes care of :
We'll buy and ship 2 flash chips (one of 8 MB, and one of 16 MB with the same voltage, consumption, timings, lack of a boot block) to those willing to participate, as long as our supplies last:
Prizes :
If you succeed, you will have made yourself you own gift: a "NumWorks++"… But, we can go a little further:
We'll buy and ship 2 flash chips (one of 8 MB, and one of 16 MB with the same voltage, consumption, timings, lack of a boot block) to those willing to participate, as long as our supplies last:
- The "official" one listed on Numworks’ schematics (64 Mbits = 8 MB) : Adesto AT25SF641-SUB-T.
- The other, with twice the storage capacity (128 Mbits = 16 MB) : Winbond W25Q128JVSIQ.
Prizes :
If you succeed, you will have made yourself you own gift: a "NumWorks++"… But, we can go a little further:
- Of course, news articles about the great [team of] hacker(s) and the possibilities made available
- Premium TI-Planet account(s)
- TI-Planet stickers and/or other goodies
If you're interested in the challenge and would you like to participate, reply to the topic and/or drop a short introduction e-mail to info@tiplanet.org
News rédigée par / written by Lionel & Adriweb.