Forum TI-Planet.org

Apres une analyse des scripts webdfu de Maxime et des sources de Epsilon, il me semble que l'acces en lecture/ecriture aux fichiers de la Numworks N0110 pourrait se faire en local avec dfu-util de la maniere suivante:
1/ lecture de l'adresse en RAM de Ion::Storage::sharedStorage()::storage en utilisant la variable platform_infos, dont l'adresse dans delta est en 0x020001c4 (0x080001c4 dans le script de Maxime).

Code: Select all

dfu-util -i0 -a0 -s 0x020001c4:0x48 -U platform.info
# lecture doit renvoyer sur n0110
# offset 0 0xDEC00DF0
# offset 0x14 adresse storage
# offset 0x18 taille
# offset 0x1C 0xDEC00DF0


(je n'ai pas compris les variantes du script de Maxime?)
Le source correspondant de Epsilon est dans ion/src/shared/platform_info.cpp

Code: Select all

  constexpr static uint32_t Magic = 0xDEC00DF0;
  uint32_t m_header;
  const char m_version[8];
  const char m_patchLevel[8];
  void * m_storageAddress;
  size_t m_storageSize;
  uint32_t m_footer;
...
    m_header(Magic),
    m_version{EPSILON_VERSION},
    m_patchLevel{PATCH_LEVEL},
    m_storageAddress(storageAddress),
    m_storageSize(Ion::Storage::k_storageSize),
    m_footer(Magic) { }


2/ echanges, le format de stockage etant decrit dans /ion/include/ion/storage.h

Code: Select all

# pour recuperer le storage
dfu-util -i0 -a0 -s adresse:taille -U numworks.storage

# pour renvoyer le storage
dfu-util -i0 -a0 -s adresse:taille -D numworks.storage


Ca ne devrait donc pas etre tres complique d'ecrire une petite interface pour echanger de la Numworks sur son PC, sans avoir a passer par le web.

Je n'ai pas ma Numworks pour le moment, mais peut-etre que quelqu'un peut confirmer?

Il y a quelque chose qui me trouble dans la lecture de l'adresse du sharedstorage, car sur Omega la variable platform_infos est a la meme adresse que sur Delta,

Code: Select all

arm-none-eabi-objdump -C -t output/release/device/n0110/epsilon.elf > dump_t

==== dump_t
...
002001c4 l     O .header   00000048 platform_infos
...


alors je me demande comment ca peut marcher avec le script https://github.com/M4xi1m3/numworks.js/blob/master/Numworks.js, plus precisement avec:

Code: Select all

   async getPlatformInfo() {
        this.device.startAddress = 0x080001c4;
        const blob = await this.device.do_upload(this.transferSize, 0x48);
        return this.__parsePlatformInfo(await blob.arrayBuffer());
    }


Y-a-t-il un mecanisme qui traduit des adresses RAM en autres adresses RAM?

(J'en profite pour signaler a l'equipe Omega que la release ne compile pas out of the box en faisant make: atom et rpn n'ont pas de Makefile (j'ai du les commenter dans build/config.mak) et il faut installer aussi un sous-repertoire themes qui est vide dans l'archive. Ca meriterait a mon avis une petite explication ou si c'est explique quelque part, d'etre plus visible).

parisse wrote:(J'en profite pour signaler a l'equipe Omega que la release ne compile pas out of the box en faisant make: atom et rpn n'ont pas de Makefile (j'ai du les commenter dans build/config.mak) et il faut installer aussi un sous-repertoire themes qui est vide dans l'archive. Ca meriterait a mon avis une petite explication ou si c'est explique quelque part, d'etre plus visible).

Comme on l'a précisé dans le README (https://github.com/Omega-Numworks/Omega/blob/omega-master/README.md), pour cloner le repository, il faut faire :

Code: Select all

git clone --recursive


Le recursive permet de cloner aussi les gitmodules (dépendances de ce repository). La liste est visible ici : https://github.com/Omega-Numworks/Omega/blob/omega-master/.gitmodules.
En suivant donc le tutoriel donné sur le README ça devrait donc marcher...

Normalement un script comme ça devrais être possible.

Comment ça se fait que dans delta le platform_infos soit dans 0x020001c4 alors que cette adresse se trouve dans le mappage de la RAM? Normalement sur tous les builds et forks d'epsilon tout se trouve en flash à l'adresse 0x080001c4 (indépendamment de la version et du modèle).

Par rapport aux checks dans la fonction qui lis le platform_infos dans Numworks.js, c'est pour supporter les anciennes versions d'Epsilon et d'Omega (à une époque le platform_info était mal fait dans Omega (entre 1.0.0 et 1.13.10 inclus je crois), et les anciennes versions d'Epsilon (avant E11) ne stockaient pas de la même manière.

Et comme précisé par Joachim, on utilise des submodules, donc il faut cloner avec l'argument --recurse-submodules

EDIT: Plus de précisions : le platform_infos est stocké dans la section .header, qui est définie en flash interne sur les deux modèles, qui se trouve en flash après l'ISR-table (qui a une taille fixe).

Sur la compilation d'Omega: en effet, ca marche si on lit attentivement le README.md, mais pas si on fait naivement un git clone de l'adresse ou si on utilise l'archive tar.gz de la release (https://github.com/Omega-Numworks/Omega/releases/tag/O1.20.2-E14). Ce serait bien de preciser que git clone tout court ne marchera pas, sans avoir a deplier n0110.

Sur platform_infos a l'adresse 0x002001c4 (avec deux 0), ce n'est pas specifique a Delta, c'est aussi le cas sur Omega, en tout cas j'obtiens la meme adresse avec arm-none-eabi-objdump. Ce qui veut dire que l'adresse en 0x08... doit marcher dans tous les cas (d'ailleurs sinon le workshop numworks ne fonctionnerait pas avec delta) et peut-etre pas celle en 0x002...

En ce qui me concerne, c'est le support de l'echange de fichiers .xw qui m'interesse (voire de .tab pour le tableur isolement). Je pourrais assez facilement recoder des fichiers sessions comme des faux scripts Python (par exemple avec un en-tete #xwaspy suivi d'une ligne tres longue ou 4 octets ascii en codent 3 binaires en utilisant uniquement 6 bits par octet pour etre entre 64 et 127), et on pourrait alors les echanger avec les workshop existants, mais je pense que ce serait mieux de faire un vrai connectivity kit en local, parce que ca permet de travailler sans connexion Internet d'abord, et surtout ca assure de controler ses donnees. Evidemment ca demande un peu plus de travail, mais ca ne me parait pas si complique que ca, il faut ecrire le code de gestion de l'archive cote PC et voir comment appeler dfu-util (soit avec system(), soit en retravaillant avec le code source de dfu-util) et faire une petite UI.

Verification faite, 0x00200000 c'est la flash interne. Mais a quoi correspond 0x08...., mystere!
Ca vaudrait le coup d'essayer si on arrive a recuperer le platform_infos en 0x00200000.

En y reflechissant, c'est peut-etre du cote de la calculatrice que le 0x08... est traduit, pour avoir une adresse cote PC independante du modele de Numworks.

J'ai compris. En lisant la doc du processeur de la Numworks, page 56, on se rend compte que la flash interne est map en 0x00200000 et en 0x08000000, mais pas avec la même interface (ITCM pour la première, AXIM pour la deuxième). Je ne comprends pas bien la différence entre les deux interfaces mais on se retrouve donc grosso modo avec un miroir de la flash. Dans Numworks.js, j'ai utilisé 0x08000000 parce que c'est ce que fait l'outil officiel de Numworks et parce que c'est là qu'est linké la partie du code en flash interne dans Epsilon.

Par rapport à Numworks.js, le transfert des fichiers autre que .py est supporté, ils ne sont juste pas décodés (les fichiers .py ont une structure spéciale : un byte pour le statut d'importation + le reste du fichier après), mais reste accessible en tant que Blob. Vous pouvez donc récupérer et insérer des fichiers .xw depuis et dans la Numworks.

Edit: Après relecture de la doc du processeur de la N0100, je me suis rendu compte que la flash est map en 0x08000000 mais pas en 0x00200000 sur la N0100. Vous feriez donc bien d'utiliser l'adresse 0x08000000.

M4x1m3 wrote:
Edit: Après relecture de la doc du processeur de la N0100, je me suis rendu compte que la flash est map en 0x08000000 mais pas en 0x00200000 sur la N0100. Vous feriez donc bien d'utiliser l'adresse 0x08000000.

Oui, c'etait la conclusion a laquelle j'etais arrive, utiliser 0x08... pour gerer toutes les Numworks.

Un autre point, je vois que dans Omega le support de DFU a ete enleve des apps externes, contrairement a Delta, cf. la fonction int extapp_getKey(bool allowSuspend, bool *alphaWasActive) dans apps/external/extapp_api.cpp, par rapport a getkey_raw() dans delta/python/port/port.cpp. Or c'est evidemment essentiel de pouvoir echanger des fichiers quand on est dans KhiCAS sans avoir a en sortir, et ca marche tres bien dans Delta (pour des fichiers .py). C'est prevu de remettre ce support? Il y a aussi des petits details qui ont change dans les traductions de touches qui vont empecher de pouvoir utiliser KhICAS au mieux depuis Omega (par exemple utilisation de shift-CUT pour acceder a la doc), qu'il serait bon de modifier.

Je vois enfin que dans extapp_fileRead et fileExists de Omega, il y a du support pour avoir des fichiers en flash externe, dans le apps.tar si j'ai bien compris, c'est quoi le statut de cet ajout? Ca me parait un peu dangereux avec le mode examen. D'un autre cote, ce serait bien d'avoir un petit systeme de fichiers en flash avec aussi acces en ecriture depuis la calc.

"le support de DFU a été enlevé des apps externes", je ne suis pas sure, je dirais plutôt qu'il n'a jamais été là ? C'est quelque chose qu'on peut rajouter si besoin oui.

Par rapport aux modifications du clavier, c'est quelque chose qu'on a délibérément décider d'enlever. Très peu d'utilisateurs d'Omega installent KhiCAS (ce qui est dommage aussi), et ça impacte le fonctionnement de tout l'OS (on a pas réussi à intégrer ça correctement sans que ça fasse des bugs à d'autres endroits).

Par rapport à fileRead, les fichiers qui ne sont pas des exécutables sont bloqués à la lecture par le driver TAR en mode examen. C'est d'ailleurs pour ça que les icônes ne s'affichent pas en mode examen sur le menu home d'Omega. Je ne vois donc pas de problème par rapport à ça. C'est aussi pour ça qu'on ne peut pas utiliser nofrendo en mode examen (puisque les roms ne sont pas marqués exécutables, elles ne peuvent être chargés par le programme).